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CHAPTER  7 
FUJITSU:    PROCESS  CONTROL  TO  AUTOMATED  CUSTOMIZATION 

The  products  Fujitsu  made  and  the  processes  it  followed  for  software 
development  closely  resembled  those  at  Hitachi.  In  basic  software,  Fujitsu  did 
not  formally  establish  a  software  factory  but  centralized  most  programming 
operations  at  a  single  facility,  the  Numazu  Works,  and  adopted  factory-like 
standards  and  controls  during  the  mid-1970s,  beginning  with  project  management 
and  product  inspection.  In  applications,  Fujitsu  began  centralizing  programming 
operations  in  1970  and  then  began  standardizing  methods  and  tools  before 
establishing  a  Software  Factory  in  1979  to  perform  detailed  design,  coding,  and 
testing,  often  for  specifications  done  in  system  engineering  departments  outside 
the  factory. 

What  distinguished  Fujitsu  most  was  the  breadth  and  depth  of  its 
competence  in  computer  hardware  and  software  development,  including  a  huge 
network  of  software  subsidiaries  throughout  Japan.  Like  Hitachi,  NEC,  and 
Toshiba,  Fujitsu  built  upon  skills  in  telephone  switching  and  electro-mechanical 
equipment  to  enter  the  computer  industry  in  the  mid-1950s.  it  adopted 
transistors  and  introduced  commercial  models  somewhat  later  than  its  leading 
Japanese  competitors,  although  Fujitsu  also  proceeded  without  foreign 
assistance,  at  least  until  investing  in  Amdahl  in  the  early  1970s,  and  relied  on  a 
talented  group  of  in-house  engineers  and  careful  study  of  U.S.  technology.  This 
strategy  of  deliberate,  independent  development  helped  Fujitsu  become  the 
largest  Japanese  computer  producer  in  1968,  in  terms  of  sales,  and  remain  in 
this  position  through  the  1980s,  with  competitive  hardware  and  software 
products  or  services   in   all   segments  of  the  Japanese  market. 

The    Nikkei    survey    data    reinforced    this    evaluation    of    Fujitsu:       It    was 
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Japan's  largest  vendor  of  computer  products  for  small,  medium,  and  large 
systems  (Tables  1.3  and  1.4).  Fujitsu  was  especially  competitive  in  sales  to 
institutions  and  government  agencies  as  well  as  to  industries  ranging  from 
information  services,  distribution,  chemicals,  electrical  machinery,  and 
construction  to  foodstuffs  (Table  1.5).  Japanese  customers  in  1988  ranked 
Fujitsu  first  in  Japanese-language  processing  software  among  all  major  firms 
competing  in  Japan.'  They  also  rated  it  ahead  of  or  equal  to  the  best  of  its 
Japanese  competitors  in  basic  system  software,  hardware  price-performance, 
applications   system-engineering   support,    and  general   satisfaction    (Table  1.6). 


THE  CORPORATE  SETTING 

Company  Outline  and  Organization 

Fuji  Electric,  an  electrical-machinery  producer  affiliated  with  Siemens  of 
Germany  and  dating  back  to  1923,  established  Fujitsu  in  1935  by  incorporating 
its  telephone  equipment  division  as  a  separate  company.  The  new  firm 
commercialized  Japan's  first  digital  calculator  in  1935  and  expanded  into 
switching  systems  and  other  electric  and  electro-mechanical  equipment,  before 
introducing  a  primitive  non-programmable  computer  in  1954.  Fujitsu  gradually 
expanded  product  development  and  marketing  for  a  range  of  communications  and 
office  equipment,  computers  and  computer  peripherals,  and  data  processing 
services.  In  the  year  ending  March  1988,  Fujitsu  had  over  52,000  employees  in 
the  parent  corporation,  with  more  than  one  out  of  five  personnel  involved  in 
software  production  or  staff  support.  Non-consolidated  sales  totalled  over  $13.7 
billion  (over  $16  billion  including  some  70  subsidiaries).  Fujitsu  led  all  Japanese 
firms  in  data-processing  sales,  which  accounted  for  over  $10  billion  (72%)  of  its 
total    revenues.      Other  major   revenue   sectors   for   Fujitsu   were  communications 

.    2  Fujitsu 


systems    (16%)    and  electron    (semiconductor)   devices    (12%). 

Fujitsu  divided  these  revenue  areas  into  more  than  a  dozen  operating  and 
marketing  groups  (Figure  7.1).  Several  divisions  produced  computer  programs 
for  internal  or  commercial  sale,  and  a  corporate  Software  Development  Planning 
Group,  established  in  1982,  directed  planning  for  tool  and  methodology  research 
and  technology  transfer  for  Fujitsu,  subsidiaries,  and  subcontractors.  The  focus 
of  this  chapter  is  the  two  largest  software  facilities:  Numazu,  the  main  site  in 
the  Computer  Group,  located  near  Mt.  Fuji  in  Shizuoka  prefecture,  which  made 
hardware  as  well  as  basic  systems  software  (operating  systems,  control 
programs,  network  software,  data  base  systems,  language  processors,  Japanese 
language  and  graphics  or  voice  processing  software,  and  automatic  translation 
programs)  for  mainframes,  and  the  Kamata  Software  Factory,  located  at  the 
Information  Processing  System  Laboratory  in  Kamata,  Tokyo.  The  latter  was 
the  main  facility  in  the  System  Engineering  Group,  which  produced  custom 
applications   software  and   application   packages. 

Fujitsu  established  the  Numazu  Works  in  1974  to  produce  the  FACOM-M 
series  mainframes  and  minicomputers,  designed  to  compete  with  IBM's 
System/370.  The  Software  Division,  housed  in  a  separate  building  (connected  to 
the  hardware  building)  constructed  in  1981,  consisted  of  two  software 
engineering  departments,  eight  development  departments,  an  inspection 
department,  and  a  Field  Support  Center.^  The  approximately  3000  software 
personnel  working  at  Numazu  included  about  1000  programmers  from  software 
houses  and  subsidiaries."  Despite  the  scale  of  operations  at  Numazu,  Fujitsu 
management  did  not  label  or  publicize  the  facility  as  a  software  factory,  since 
groups  worked  in  integrated  teams  to  produce  unique  systems  products. 
Nonetheless,  in  addition  to  scale,  the  level  of  integration  in  operations  and 
management,    begun    around    1974-1975,    and    the    centralization    of   most    basic- 
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software  programming   at  this   facility   by    1984,    made   Numazu   indistinguishable 
from  counterpart  facilities   referred  to  as  software  factories  at  Hitachi  and  NEC. 

Fujitsu  opened  the  Kamata  Software  Factory  in  1979  to  continue  a  decade- 
long  effort,  beginning  with  Fujitsu's  establishment  of  the  Information  Processing 
Systems  Laboratory  in  1970  to  house  the  Systems  Engineering  Group,  to 
centralize  and  rationalize  custom  programming  for  banks,  securities  firms, 
government  departments,  and  manufacturing  and  distribution  companies.  The 
Software  Factory  Department  performed  programming  and  module-test 
operations,  based  on  specifications  received  from  approximately  4000  system 
engineers  in  the  Systems  Engineering  Group,  and  also  did  increasing  amounts  of 
system  design.  The  factory  was  comparable  in  size  to  comparable  facilities  at 
Hitachi  and  NEC,  with  approximately  1500  personnel  in  1987.  Kamata  was 
exceptional,  however,  in  that  merely  200  or  so  employees  were  from  Fujitsu  and 
10  to  30  from  its  subsidiaries.  The  remainder  --  nearly  1300  programmers-- 
were  employees  of  independent  software  houses,  with  most  remaining  at  their 
parent  firms,  linked  by  networks  and  terminals  to  computers  and  data  bases  in 
the  Software  Factory. °  This  extensive  use  of  subcontractor  personnel  allowed 
Fujitsu  to  retain  the  benefits  of  a  centralized,  standardized  factory 
infrastructure  and  still  accommodate  variations  in  demand  for  customized 
programming  without  hiring  too  many  permanent  employees,  which  were 
relatively  scarce  and  expensive  in  Tokyo. 

In  addition  to  the  personnel  counted  as  part  of  the  Software  Factory 
Department,  Fujitsu  could  also  draw  on  58  software  subsidiaries  employing  over 
14,000  programmers  for  system  engineering,  applications  programming,  basic- 
software  development,  and  microcomputer  programming  (Table  7.1).  Software 
houses  working  on  a  regular  basis  with  Fujitsu  brought  total  available  software 
personnel   in  the  Fujitsu  group  circa   1987-1988  to  about  20,000.^     Not  only  did 
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these  numbers,  which  exceeded  the  amount  of  programmers  in  the  NEC,  Hitachi, 
and  Toshiba  groups,  attest  to  the  importance  (and  managerial  complexities)  of 
software  development  to  Fujitsu.  So  did  their  rapid  expansion,  as  Fujitsu  and 
its  affiliates  added  from  1000  to  3000  software  and  related  personnel  annually 
during  the  middle  and   late   1980s. 

Entry  into  Computers 

Fujitsu  historians  mark  the  company's  entrance  into  the  computer  business 
with  the  1954  introduction  of  a  dedicated  accounting  machine,  the  FACOM  100. 
This  was  not  a  programmable  computer  but  was  hardwired,  using  electro- 
magnetic relay  switches  adapted  from  telephone  switchboards.  Fujitsu 
introduced  several  other  relay  computers  before  adopting  parametron  circuits  in 
1958,  following  the  lead  of  Hitachi  and  NEC,  although  these  computers  also 
functioned  as  dedicated  calculating  machines.  Again  following  Hitachi  and  NEC, 
Fujitsu  began  working  on  a  transistor-based,  programmable  computer  in  1958 
and  introduced  its  first  commercial  models  in  1961,  for  business  applications. 
Management  then  signaled  a  major  commitment  to  the  new  industry  by 
establishing   a  computer  division    in    1963.^ 

Fujitsu  approached  IBM  for  assistance  in  computer  development,  but  when 
this  initiative  failed  management  pursued  the  business  independently,  investing 
in  in-house  research  as  well  as  frequently  sending  company  engineers  to  the 
United  States  to  learn  from  American  firms  and  university  researchers. 
Prospects  for  Fujitsu  seemed  dim,  since  it  was  already  behind  Hitachi,  NEC,  and 
Toshiba  due  to  a  late  switch  to  transistors  and  the  assistance  U.S.  firms  were 
providing  Japanese  competitors  But  when  the  flow  of  new  models  from  the  U.S. 
all  but  stopped  during  the  later  1960s,  as  GE  and  RCA  prepared  to  exit  the 
computer    business,    and    Honeywell    reduced    its    product    development    efforts, 
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Fujitsu    engineers    were   able   to   offer   hardware   superior   to   that   available   from 
Hitachi,    NEC,    or  Toshiba. 

Fujitsu's  most  competitive  machines  were  the  230  series  of  small,  medium, 
and  large  mainframes,  initially  introduced  in  1965  with  transistors  but  upgraded 
in  1968  with  more  advanced  integrated  circuits.  These  models  attracted  many 
Japanese  customers,  especially  in  the  banking  industry  and  at  universities,  due 
to  their  low  prices  and  powerful  processing  capabilities.  The  Japanese 
government  also  aided  these  sales  by  placing  restrictions  on  purchases  of  non- 
Japanese  computers,  including  models  from  Japan  IBM.  Nonetheless,  the 
popularity  of  the  230  models  made  Fujitsu  Japan's  largest  computer  manufacturer 
in  1968  and  helped  computer  revenues  exceed  50%  of  Fujitsu's  sales,  for  the 
first  time,    in   1970.^^ 

Independent  development  might  not  have  worked  so  well  as  a  strategy 
without  the  contribution  of  Toshio  Ikeda  (1923-1974),  a  graduate  of  the  Tokyo 
Institute  of  Technology  who  had  entered  Fujitsu  in  1946.  After  designing 
telephone  switching  equipment,  he  moved  into  computers  and  quickly  gained 
recognition  as  Japan's  most  talented  design  engineer.  Ikeda's  fame  and 
interests  led  him  in  1969  to  meet  Gene  Amdahl,  his  counterpart  at  IBM  who  had 
designed  the  System/360  and  then  left  IBM  in  1970  to  found  the  Amdahl 
Corporation,  to  produce  larger  IBM-compatible  mainframes.  Their  meeting  began 
a  relationship  between  Fujitsu  and  the  Amdahl  Corporation  that  continued 
through  the  1980s  and  assisted  Fujitsu  in  implementing  a  key  change  in  its 
product  strategy:      adoption  of    IBM  compatibility. 

Fujitsu  and  Amdahl  were  logical  partners  since  Amdahl  needed  financing 
and  Fujitsu  managers  believed  they  could  expand  their  market  share  with 
computers  that  competed  directly  for  IBM  customers.  Hitachi  managers  had 
reached    a    similar    conclusion,    and,    with    MITI's    encouragement,     Fujitsu    and 
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Hitachi  agreed  to  standardize  their  mainframe  architectures  and,  without  jointly 
developing  hardware  or  software,  introduce  models  that,  together,  matched  all 
the  segments    IBM's   System/370  family  covered. 

Fujitsu  also  became  Amdahl's  largest  shareholder  after  the  premature  death 
of  Ikeda  in  1974  and  the  recognition  of  Fujitsu  executives  that  they  could  use 
some  assistance  in  hardware  design.    "^    (Amdahl,  with  the  exception  of  a  version 

of    the    UNIX    operation    system,     did    not    cooperate    with    Fujitsu    in    software 

1  '^ 
development.'"')        With     help    from    Amdahl    to    produce     IBM-compatible    logic 

circuits,  utilizing  the  most  advanced  semiconductor  technology  available,   Fujitsu 

by     the    mid-1970s     was     able    to    deliver     hardware    comparable    to     IBM     in 

performance  at  given   price  ranges.      These  machines   proved  competitive  inside 

and  outside  Japan:     Fujitsu  manufactured  central-processing  units  for  Amdahl  as 

well    as    ICL    in    Great    Britain,    modified    to    their    specifications,    and    sold    its 

complete    mainframes    to    Siemens    for    marketing    in    Europe    under   the    Siemens 

label. 14 

Software  Strategy:      Products  and   Process 

Until  the  M  series,  successful  competition  in  Japan  required  Fujitsu  to 
offer  products  comparable  in  functions  (and  price-performance)  to  other 
Japanese  or  foreign  hardware  and  software  available  in  Japan.  This  involved 
studying  "state-of-the-art"  products  as  well  as  attempting  some  real  innovations, 
such  as  to  accommodate  two  central-processing  units  in  the  largest  230-series 
model  computer.  But  Fujitsu's  switch  to  IBM  compatibility  for  domestic  and 
exported  mainframes  affected  software  product  and  process  development  in 
several   ways. 

To  a  large  extent,  all  producers  of  IBM-compatible  hardware  followed 
external  specifications   --  descriptions  of  what  products  should  do,    rather  than 
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how  they  might  operate  internally  --  IBM  initially  set  with  the  System  360. 
While  IBM  eventually  challenged  the  legality  of  this  action  as  well  as  modified 
its  products  to  make  them  more  difficult  to  emulate,  compatible  producers  seem 
to  have  proceeded  on  the  assumption  that,  since  OS/360  was  in  the  public 
domain,    they  could   follow  OS/370  and   later  standards.  While  other  authors 

have  recounted  the  details  of  suits  by  and  against  .IBM,  there  are  several  issues 
relevant  to  the  subject  of  software-development  management. 

Most  significant  was  that  compatible  producers  were  able  to  avoid  the 
more  uncertain  aspects  of  new-product  development,  such  as  defining  new 
functions  or  creating  new  standards.  For  basic  software,  Fujitsu  managers 
estimated  that  designing  external  specifications  took  approximately  10%  of  total 
man  hours  (compared  to  10%  for  internal  specifications,  20%  for  program  design, 
30%  for  programming  or  coding,  and  another  30%  for  testing).'"  This  meant 
that  relying  on  IBM's  external  specifications  probably  helped  firms  reduce  man 
hours  for  new  products.''  Commentators  on  the  industry  have  supported  this 
notion,  claiming  that  most  mainframe  basic-software  development  at  Fujitsu  (and 
some  at  Hitachi  as  well)  between  the  mid-1970s  and  early  1980s  consisted  of 
working  backward  from  IBM  manuals,  rather  than  inventing  new  procedures  or 
functions.  Indirect  evidence  of  this  was  the  1988  settlement  between  IBM  and 
Fujitsu,  which  called  for  Fujitsu  to  pay  IBM  several  hundred  million  dollars  in 
licensing  fees  plus  an  annual  fee  if  it  wanted  to  review  licensed  IBM  manuals 
and    source    code,     primarily    to    understand    the    interface    specifications    to 

1  Q 

facilitate  the  continued  production  of   IBM-compatible  hardware.'*^ 

Yet  the  advantages  of  compatibility  were  not  absolute.  First  of  all,  IBM, 
as  the  leader,  by  definition,  in  the  IBM-compatible  market,  was  able  to  set  most 
standards  and  decide  schedules  (and  some  prices  as  well)  for  new  product 
introductions.     In  custom  applications  programming,  the  bulk  of  software  demand 
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in  Japan,  existing  software  from  IBM  or  other  vendors  might  provide 
suggestions  on  how  to  design  a  particular  system.  But  customer  needs  were 
usually  different  enough  so  that  it  was  rarely  sufficient  to  follow  existing 
specifications.  Because  projects  generally  had  to  invest  the  time  to  design  a 
full  set  of  external  specifications,  IBM  compatibility  probably  offered  firms  such 
as  Fujitsu  little  savings  in  manpower  for  applications  compared  to  basic- 
software  development. 

At  the  same  time,  maintaining  compatibility  with  new  IBM  hardware  proved 
increasingly  difficult  after  the  late  1970s,  when  IBM  began  to  embed  more 
functions  in  hardwired  chips  that  were  difficult  to  duplicate.  Mainframe 
producers  committed  to  IBM  compatibility  had  to  devote  more  time  to  working 
backwards  from  announced,  often  incomplete  specifications,  and  would  probably 
always  lag  behind  in  new-product  introductions  as  they  waited  for  IBM  to 
introduce  its  systems.  Japanese  firms  (and  Amdahl)  competed  by  advertising 
hardware  that,  while  sometimes  later  in  delivery  than  IBM  products,  offered 
superior  "price-performance."  This  goal  --  a  combination  of  competitive  prices 
and  performance  --  required  a  mode  of  design  and  production  management 
oriented  less  toward  product  innovation  and  more  toward  incremental  product 
improvements  following  IBM  as  well  as  process  efficiency  in  all  phases  of  basic 
hardware  and   software  development. 

In  both  basic  and  applications  software,  similar  to  other  Japanese  firms, 
Fujitsu  managemervt  In  the  early  1970s  began  promoting  process  rationalizations 
aimed  at  the  "accumulation  and  improvement  of  technology,"  both  individual  and 
organizational.  According  to  internal  training  materials,  this  rationalization  for 
software  production  centered  on  three  broad  areas:  development  technology, 
specialization,    and  mechanization/automation    (Figure  7.2). 

The  drive  to  improve  development  technology  within   Fujitsu   in   the   1970s 
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and  early  1980s  consisted  of  making  greater  use  of  fundamental  advances  in 
software  engineering  coming  mainly  from  the  United  States  and  Europe: 
higher-level  languages  (though  standardized  for  in-house  use),  modularization 
-Nk  and  structured  methods  for  design  and  programming,  quantified  controls  for 
product  inspection  and  process  reviews  to  insure  product  reliability  and  reduce 
time  spent  on  fixing  or  altering  programs.  Another  aspect  of  development 
technology  aimed  at  minimizing  the  volume  of  new  code  programmers  had  to 
write  through  what  managers  called  "common  development":  (1)  writing  program 
designs  in  a  computer  language  or  in  flow-chart  form  that  could  be  compiled 
into  different  languages  and  storing  the  components  in  a  reusable  library;  and 
(2)  designing  basic  programs  or  components,  such  as  compilers,  for  use  in  more 
than   one  of   Fujitsu's  operating   systems.    ^ 

Specialization  included  the  establishment  of  development  organizations 
dedicated  to  different  types  of  software  and  functions,  such  as  the  Numazu 
Works  Software  Division  and  the  Kamata  Software  Factory,  smaller  facilities 
linked  by  on-line  networks,  as  well  as  subsidiaries  specializing  in  various  areas 
or  providing  regional  system-engineering  services  throughout  Japan.  ■^^  As  at 
Hitachi  and  NEC,  these  subsidiaries,  supplemented  by  long-term  arrangements 
with  independent  software  houses,  provided  not  only  regional  services  to 
customers  and  specific  applications  skills,  but  they  allowed  Fujitsu  to  add  less 
expensive  and  temporary  capacity  for  programming  operations.  Another  strategy 
related  to  the  concept  of  specialization  was  to  have  development  groups  with 
special  knowledge  of  common  applications  gradually  write  more  software 
packages,  especially  for  personal  and  office  computers,  and  integrate  these 
packages  with   new  software  to  produce   semi-customized   systems. 

Mechanization  or  automation  referred  to  the  use  of  computer-aided  tools 
to    support    design,     coding,     testing,     and    maintenance,     including    program 
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generators  and  reuse-support  systems,  which  offered  the  potential  of  raising 
productivity  and  quality  simultaneously.  Fujitsu  management  also  viewed  the 
application  of  automation  and  mechanization  to  control  technology,  in  the  form 
of  tools  for  planning,  project  management,  testing,  and  quality  evaluation, 
integrated  with  standards,  manual  procedures,  and  practices  such  as  quality 
circles,  as  another  way  to  support  development  technology  and  specialization. 
Again,  there  was  nothing  unusual  in  Fujitsu's  approach  to  automating  aspects  of 
software  development,  except  perhaps  in  degree  of  emphasis,  particularly  in 
applications   programming. 


BASIC  SOFTWARE 

Product- Process  Development 

Fujitsu's  decision  in  the  1960s  to  develop  computer  products  independently 
challenged  company  engineers  to  master  not  only  hardware  design  but  also 
software  programming.  A  sampling  of  packages  Fujitsu's  basic-software 
personnel  produced  between  1962  and  1984,  listed  in  Table  7.2,  provides  some 
indication  of  the  scope  and  scale  of  their  efforts:  From  1960  onward,  Fujitsu 
offered  an  increasingly  wide  range  of  compilers,  operating  systems,  and  tools,  in 
addition  to  customized  programs  and  integrated  hardware-software  systems  such 
as  for  banks,  government  agencies,  manufacturing  and  distribution  firms,  and 
telecommunications  systems.  Fujitsu's  offerings  seemed  comparable  to  products 
from  other  Japanese  and  U.S.  firms,  and,  judging  by  success  in  the  market 
place,  they  were  possibly  superior.  Most  important  for  the  subject  of  this 
book,  as  the  discussion  below  indicates,  Fujitsu  managers  and  personnel  made  a 
series  of  interrelated  efforts  to  create  an  integrated,  standardized  process  and 
organization   for  basic-software  production   as   products   became  more  numerous 
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and   complex. 

Fujitsu's  experience  with  software  development  began  in  the  early  1960s 
with  the  introduction  of  several  transistorized  computers,  since  the  relay  and 
parametron  computers  of  the  1950s  were  either  hard-wired  or  required  only 
minimal  programming.  Even  the  first  transistorized  machines  did  not  have 
"modern"  operating  systems  but  performed  simple  batch-processing  operations 
and  only  required  specialized  routines  and  language  compilers.  Like  other  firms 
pioneering  in  the  computer  industry,  Fujitsu  gradually  introduced  other  software 
systems,    following    IBM's    lead  conceptually,    if   not  technologically. 

An  important  early  product,  because  it  exposed  Fujitsu  engineers  to  new 
types  of  programs  and  computer  languages,  was  the  FONTAC,  delivered  in  1964 
to  the  Electronics  Industry  Promotion  Association  of  Japan.  This  was  a 
cooperative  project  among  Fujitsu,  NEC,  and  Oki  Electric,  which  MIT!  sponsored 
to  encourage  domestic  firms  to  build  a  large-scale  computer  roughly  equivalent 
to  IBM's  7090  machine,  which  IBM  had  introduced  in  1960.  Fujitsu  designed  the 
main  processor  and  the  card  punch  equipment,  while  NEC  and  Oki  Electric  made 
the  sub-processors  and  input/output  devices.  Fujitsu  also  took  charge  of 
programming,  with  assistance  from  NEC  and  Oki  engineers,  several  Japanese 
professors,  and  a  few  U.S.  consultants.  The  software  Fujitsu  provided  consisted 
of  a  "monitor,"  based  on  earlier  control  programs  available  in  Japan,  as  well  as 
ALGOL,  COBOL,  FORTRAN,  and  ASSEMBLER  compilers;  a  library  editor;  a  sort 
generator;  an  executable  coded  tape  editor;  utility  programs;  and  several  object 
(applications)     programs.        Fujitsu     later    modified    the    FONTAC    monitor    and 

introduced   this    in    1965   as    MONITOR    II    with    its    230-50   mainframe,    Fujitsu's 

21 
commercial   version  of  the   FONTAC."' 

A    more    serious    challenge    Fujitsu    engineers    faced    in    the    1960s    was    to 

develop   an   operating   system  comparable,    at   least  in   basic  functions,    to   IBM's 
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OS/360,  which  had  set  new  standards  for  the  entire  industry.  Fujitsu  needed 
this  software  for  the  upgraded  230-series  models,  especially  the  dual-processor 
230-60,  which  incorporated  integrated  circuits  and  offered,  for  the  time, 
extensive  processing  capabilities.  The  demands  of  this  programming  led  Fujitsu 
to  establish  a  separate  department  for  the  TOO  or  so  employees  needed  to  build 
the  operating  system,  MONITOR  V.  Fujitsu  completed  this  in  1968,  after  two 
years  of  development  and   numerous   tribulations. 

According  to  several  Fujitsu  engineers,  MONITOR  V  was  extremely 
difficult  to  develop  due  to  the  dual-processor  architecture,  then  available  only 
in  U.S.  military  computers.  Furthermore,  Fujitsu  had  not  yet  designed  a 
sophisticated  operating  system  even  for  one  processor,  let  alone  two,  and  while 
Fujitsu  used  OS/360  as  a  conceptual  model,  the  360  architecture  was  completely 
different.  Fujitsu  engineers,  including  Ikeda  and  the  head  of  the  project  as 
well  as  the  new  software  department,  Takuma  Yamamoto  (Fujits  resident  in 
1988),  made  several  trips  to  the  U.S.   to  seek  assistance  from  A  can  software 

houses  and  computer  manufacturers.     This  was  typical  of  Fu'  which,   rather 

than   buying  technology  from  the  U.S.,    encouraged  perso'  to  travel  abroa'^ 

frequently,     especially    to    the    U.S.,     to    visit    consultants,     suppliers, 
competitors. 

Fujitsu  still  required  assistance  to  complete  and  debug  the  system, 
delivered  in  an  initial  version  to  the  Kyoto  University  Computer  Center  in  1969, 
months  behind  schedule.  Kyoto  University  personnel  helped  correct  problems 
and  finish  the  programming.  In  retrospect,  MONITOR  V  and  the  230-series 
overall  were  major  successes  commercially  and  for  the  lessons  in  management 
and  organization   they  forced   Fujitsu  to  encounter. 

MONITOR  V  demonstrated  to  top  management,  for  the  first  time,  the 
importance    of    effectively    managing     large-scale    software    development.         In 
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recognition  of  his  success  in  producing  MONITOR  V,  company  executives  in 
1968  promoted  Yamamoto  to  director  of  programming  for  both  systems  and 
applications.  A  1949  graduate  of  Tokyo  University's  electrical  engineering 
department,  Yamamoto,  like  Ikeda,  had  started  in  hardware,  designing  telephone 
switching  equipment  and  then  relay  computers  before  moving  to  data-processing 
equipment  design  and  then  MONITOR  V.  As  he  rose  in  the  executive  ranks  to 
corporate  director  in  1975  and  company  president  in  1981,  Yamamoto  made 
certain  that  Fujitsu  provided  sufficient  direction  and  resources  to  continue 
improving   its   software-development  process   and  organization. 

Another  benefit  of  MONITOR  V  was  that  it  helped  prepare  Fujitsu  for  the 
major  task  of  the  1970s:  to  develop  a  more  advanced  operating  system 
comparable  to  OS/370  that  would  serve  the  M-series  hardware.  Fujitsu 
managers  in  the  early  1970s  introduced  a  succession  of  new  procedures  and 
control  systems  for  successor  products,  beginning  with  MONITOR  VII,  completed 
in  1974.  To  minimize  the  development  effort  for  the  M-series  software,  Fujitsu 
also  decided  to  produce  three  operating  systems  to  cover  the  small,  medium,  and 
large  mainframes,  in  contrast  to  the  five  separate  programs  IBM  offered  for  its 
370-series  models.  The  first  version  of  the  operating  system  for  its  largest 
mainframes,  OS  IV/F4,  Fujitsu  successfully  delivered  in  1975,  and  followed  this 
with  versions  for  mid-size  and  small  mainframes  in  1977.  These  were  more-or- 
less  on  time  and  commercial  successes,  although  the  scale  and  complexity  of  the 
M-series  programs  again  convinced  Fujitsu  management  to  take  another  series 
of  steps  to  upgrade  and  standardize  procedures,  methods,  and  tools  for  all 
phases  of  software  development  and  control.  ^•^ 

Another  manager  who  rose  to  prominence  during  this  period  was  Mamoru 
Mitsugi,  in  1988  a  Senior  Executive  Director  and  head  of  Fujitsu's  Systems 
Engineering    Group.         He    would     later    carry    forward    the    idea    of    process 
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rationalization  to  the  establishment  of  a  software  factory  for  applications  in 
1979.  In  the  meantime,  Mitsugi  headed  the  effort  to  develop  the  M-series  basic 
software  and,  at  the  same  time,  to  systematize  process  and  quality  control  in 
the  entire  division.  Like  his  predecessors,  Mitsugi  had  worked  as  a  hardware 
designer,  developing  telephone  exchange  systems  Fujitsu  supplied  to  NTT.  But 
he  was  one  of  the  first  managers  to  have  an  extensive  background  in  software 
inspection,  initially  for  programs  supplied  to  NTT  along  with  switching 
equipment,  before  joining  the  basic-software  group  to  head  operating-systems 
inspection   in   1973. 

While  Japanese  firms  separated  commercial  software  development  from  NTT 
contracts,  working  for  NTT  in  the  early  1970s  clearly  shaped  the  thinking  and 
practices  of  Mitsugi  as  well  as  his  counterparts  at  NEC  and  Hitachi. 
Implementing  specifications  received  from  NTT  for  systems  such  as  DIPS 
(Distributed  Information  Processing  System),  and  producing  the  hardware  and 
software  in  conjunction  with  other  firms,  required  all  contractors  to  establish 
and  follow  product  and  process  standards.  Since  these  were  even  more  rigorous 
than  in  commercial  departments,  because  of  NTT's  exacting  standards,  managers 
who  moved  from  NTT  work  to  commercial  systems  brought  with  them  higher 
management  standards.  For  example,  after  joining  the  basic-software  group, 
Mitsugi  compared  its  product  and  process  control  operations  and  decided  he  had 
to  strengthen  the  inspection  department  as  well  as  expand  the  department's  role 
to  improving  process  standardization  rather  than  just  inspecting  finished 
products. '^"^  He  also  realized  Fujitsu  had  to  make  these  long-term  improvements 
while  meeting  short-term  development  targets  --  an  intractable  problem  for 
commercial   divisions   during  the   1970s   due  to   rapid   growth    in   demand: 

At    the    time,    NTT    was    very    advanced    in    its    thinking.       The    DIPS 
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software  was  really  a  large  system.  Since  three  companies,  including 
us,  had  to  develop  the  software,  standardization  was  essential.  My 
impression  was  that  NTT  was  able  to  devote  more  effort  to  software 
phase  divisions  and  carrying  out  work  standardization  than  we  were 
able  to  do  in  the  private  sector.  Of  course,  we  influenced  that 
thinking,  too,  since  there  was  an  interchange  among  us,  an  exchange 
of  information.  .  .  .  This  was  a  period  of  rapid  growth,  and  demand  for 
software  was  increasing  rapidly  too.  We  had  to  write  programs 
quickly  to  meet  this  demand,  and  worried  about  preparing 
documentation  later.  In  other  words,  we  gave  top  priority  to  writing 
programs.  This  tended  to  defeat  documentation  and  program 
conformance.  In  the  long  run  this  is  self-defeating,  and,  like  NTT,  it 
is  better  to  review  and  inspect  every  phase,  and  get  rid  of  as  many 
bugs  as  possible  in  each  phase.  But,  in  the  private  sector,  since 
software  development  must  have  more  constraints  on  time  and  costs, 
even  though  we  were  aware  of  this  problem,  there  was  not  much  we 
could  do.'^'* 

Product.    Process,   and  Quality  Control 

An  important  characteristic  of  Fujitsu's  development  approach  and 
organization  for  basic  software  was  the  gradual  integration  of  controls  for 
product,  process,  and  quality.  Direction  of  Fujitsu's  efforts  in  these  areas,  as 
at  NEC,  came  from  the  Inspection  Department  (later  renamed  the  Quality- 
Assurance  Department)  in  the  Numazu  Works's  Software  Division,  which  Mitsugi 
headed  before  becoming  division   manager  in    1974. 

According  to  a  chronology  the  department  prepared,  these  efforts  fell  into 
three   main    phases:       prior   to    1970,    when    Fujitsu    had    no    set    procedures    and 
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managers  allowed  programmers  to  test  software  at  their  own  discretion;  1970- 
1978,  when  Fujitsu  set  up  its  first  product  and  process  standards  and  formal 
systems  for  inspection  and  quality  control;  and  the  period  after  1978,  when 
Fujitsu  began  placing  more  emphasis  on  structured  design  and  programming 
techniques  and  established  the  procedures  that  formed  the  basis  of  its  current 
practices.  Distinguishing  the  last  phase  was  a  broadening  of  the  Inspection 
Department's  concerns  to  include  not  simply  testing  and  documentation 
conformance,  or  product  evaluation,  but  analysis  of  the  development  process 
itself   (Table  7.3). 

While  the  process  rationalization  this  chronology  details  closely  resembled 
process  evolution  at  other  Japanese  and  U.S.  firms,  Fujitsu  managers  appeared 
to  have  some  special  emphases  rather  early  on.  One  was  to  view  inspection  and 
quality  more  from  the  perspective  of  the  customer  than  in  an  absolute  sense, 
such  as  zero  defects,  which  Hitachi  tended  to  do.  This  orientation  emerged 
during  the  development  of  MONITOR  V,  when  Fujitsu  established  a  program 
testing  section  in  1968  to  evaluate  software  by  comparing  specifications  stated 
in  manuals  to  product  performance.  Assisting  designers  in  debugging  had  been 
the  group's  primary  function.  The  next  step  came  in  1971,  with  the  creation  of 
formal  product-inspection  procedures,  such  as  requiring  completed  software  and 
manuals  to  pass  a  formal  inspection  process  before  release  to  the  customer.  To 
manage  this,  Fujitsu  instituted  systems  for  "product  handling"  as  well  as 
evaluation  and  registration.  The  product-handling  procedures  required  that  the 
source  code,  manuals,  and  other  documentation  not  only  agree  but  that 
development  groups  bring  these  product  components  to  the  inspection 
department  together.  Previously,  software  was  sometimes  completed  and  released 
without  proper  documentation  or  checking.  After  1971,  however,  no  product 
received    a    registration    number,    necessary   for    release   to   customers,    without 
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meeting  these  requirements  and  gaining  the  formal  approval  of  the  Inspection 
Department. 

After  making  some  progress  in  product  control,  Fujitsu  managers  turned 
more  to  defect  control.  During  1973-1978,  Fujitsu  launched  three  interrelated 
efforts:  standardizing  software  development  practices,  collecting  quality  and 
performance  data,  and  applying  quality-control  techniques  used  in  other 
divisions  to  software.  A  planning  section  organized  in  1972  oversaw  these 
initiatives  for  the  first  few  years.  In  recognition  of  the  increasing  scale  of 
operations,    Fujitsu   also  elevated   basic   software  to  divisional    status   in    1974. 

Increasing  product  size  and  complexity  also  persuaded  Fujitsu  managers  to 
pay  more  attention  more  to  project  management  as  well  as  process 
standardization.  During  1973-1975,  the  division  started  a  Development  Planning 
and  Report  System,  which  set  up  formal  work-estimation  procedures  for  project 
managers  to  use  in  estimating  man-power  needs,  quality  objectives,  product 
objects,  and  schedules.  As  an  example  from  1984  shows,  the  system  did  not 
simply  divide  authority  or  tasks  functionally  but  required  different  groups  to 
share  responsibility  for  quality,  planning,  and  control  in  all  development  and 
testing  phases   (Table  7.4). 

The  chronology  also  charts  the  application  of  computer-aided  tools  to 
process  control  and  their  integration  with  standardized  methods.  For  example, 
in  1975-1976,  to  automate  data  collection  for  quality  and  budget  measurements, 
Fujitsu  introduced  BSMS  (Basic  Software  Project  Management  Support  System), 
after  two  years  of  research  and  trials.  BSMS  supported  new  project- 
management  and  development  procedures  and  gradually  became  more  valuable  as 
a  tool  for  estimating  schedules  and  monitoring  the  development  process,  as  well 
as  for  aiding  testing  and   inspection. 

BSMS    and   the   Development    Planning    and    Report   System  continued   to   be 
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the  centerpieces  of  Fujitsu's  production-management  system  for  basic  software 
in  the  1980s.  The  systems  worked  as  follows:  First,  project  managers  had  to 
submit  a  product-number  application  to  begin  a  project.  If  their  superiors 
approved,  they  submitted  a  budget.  The  development  and  planning  documents 
also  required  a  market  survey  and  basic-design  specifications  listing  functional, 
performance,  and  reliability  objectives,  as  well  as  estimates  of  manpower  and 
machine  time.  The  control  system  then  centered  on  the  development  and 
planning  documents  and  monthly  reports  of  actual  work  hours,  computer  time, 
and  phase  completions,  which  BSMS  tracked  and  compared  to  the  initial 
estimates.  ^"^ 

The  development  process  and  controls  followed  a  conventional  life-cycle 
model:  basic  design,  functional  and  structural  design,  detailed  design  and 
coding,  unit  and  combined  test,  component  and  system  test,  product  inspection, 
delivery  and  maintenance.  Fujitsu  had  used  PERT  charts  to  manage  these 
phases  for  MONITOR  VII  but  found  they  did  not  work  well  and  switched  to  bar 
charts  in  the  mid-1970s,  generated  manually  at  first  and  then  automatically 
through  the  on-line  BSMS  system.  The  introduction  of  BSMS  also  helped  the 
Software  Division  compile  and  maintain  an  "estimation  handbook"  containing 
actual  data  on   past  projects  to  guide  managers   in   their  estimates. 

Completion  of  functional  and  structural  design  required  documents  detailing 
the  function  of  each  system  component,  module  structure,  and  interfaces 
between  each  module,  plus  a  testing  plan.  Detailed  design  required  flow-chart 
and  tabular  documentation  on  the  internal  structure  of  each  module,  and  input 
and  output  structure.  At  the  completion  of  unit  and  combined  test,  Fujitsu 
required  a  programming  report,  which  included  the  detailed  design 
documentation,  review  reports,  test  specifications  and  results,  as  well  as  the 
source  modules.      After  system  test,    the  testing   report  documentation   included 
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the  inspection   specifications,    test  specifications  and   results,    and  the  test  set. 
Final   inspection   generated  another  set  of   results. 

The  most  important  quality  measures  Fujitsu  used  in  the  1970s  were 
reliability  in  component  test,  conformance  to  documentation,  number  of  bugs 
detected,  and  mean  time  between  failures.  Main-factor  analysis  techniques, 
introduced  in  1974  and  influenced  by  practices  at  Hitachi,  required  testers  to 
sort  through  intermediate  test  data  to  identify  sources  of  bugs,  before  final 
testing.  Standardizing  testing  and  review  procedures  was  particularly  important, 
because  Fujitsu  previously  had  not  adopted  a  consistent  approach  for  predicting 
and  eliminating  bugs.  Individual  programmers  decided  which  tests  to  run, 
without  formal  planning  or  supervision.  Better  control  in  this  area  then  allowed 
Fujitsu  in  the  later  1970s  to  track  other  measures,  such  as  software 
functionality  and  portability. 

In  the  period  after  1979,  Fujitsu  emphasized  three  themes:  Quality 
Assurance  Through  Organization,  Diffusion  of  Inspection  Ideas  Through 
Horizontal  Development,  and  Advancement  of  Quality  Concepts.  The  notion 
underlying  Quality  Assurance  Through  Organization  was  to  make  quality 
assurance  activities  part  of  the  formal  organizational  and  job  structure, 
especially  in  design  and  planning,  rather  than  a  function  restricted  to  the 
Inspection  Department.  Fujitsu  implemented  this  new  emphasis  by  instituting  in 
1979-1980  a  "phase  completion  reporting  system,"  resembling  the  design-review 
systems  used  at  other  firms,  and  then  a  new  version  of  its  Development 
Planning  and  Report  System.  The  new  reporting  system  required,  for  the  first 
time,  programmers  and  managers  to  collect  productivity  data.  Standardized 
productivity  data  then  allowed  Fujitsu  to  introduce  standard  times  for  worker 
performance  in  1980,  based  on  actual  previous  data  for  different  types  of 
software,    and    incorporating   quality  objectives.      Although    Fujitsu   was   several 
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years  behind  Hitachi,  standard  times  quickly  became  the  basis  of  project 
management. 

Diffusion  of  Inspection  Ideas  Through  Horizontal  Development  referred  to 
deliberate  efforts  to  spread  good  thinking  and  practices  regarding  quality 
control  beyond  one's  small  group.  The  mechanism  Fujitsu  used  was  to  create  a 
"Quality  Assurance  Liaison"  (QAL)  --  a  system  of  regular  meetings  where 
different  departments  and  projects  shared  information  on  bugs  and  other 
quality-related  data.  As  part  of  this  initiative,  Fujitsu  established  other 
quality-control  measures,  including  small  groups  (like  quality  circles),  initiated 
for  software  in  1980  as  part  of  the  company-wide  High- Reliability  Program. 
Advancement  of  Quality  Concepts  centered  on  lectures,  workshops,  and  measures 
dealing  with  interpretations  of  product  quality  that  extended  beyond  "zero  bugs" 
to  characteristics  such  as  product  design,  function,  performance,  ease  of  use, 
and  maintainability,    as   U.S.    experts   like  Barry   Boehm  encouraged. 

Fujitsu  managers  interpreted  these  efforts  as  constituting  a  transition  from 
process  control,  as  in  the  1970s,  to  "Total  Quality  Control"  or  TQC.  A  term 
coined  during  the  1950s  in  the  U.S.  but  more  popular  among  Japanese  firms 
since  the  1960s,  TQC  represented  comprehensive  quality-assurance  measures  that 
covered  product  planning,  design,  manufacturing,  and  service,  rather  than  simply 
inspection  after  production.  The  origins  of  the  TQC  movement  in  Fujitsu  date 
back  to  1966,  when  management  launched  its  High-Reliability  Program,  primarily 
in  hardware  development  and  manufacturing  divisions.  Fujitsu's  efforts  in  basic 
software  gradually  came  to  include  procedures  for  project  and  budget  control, 
work  and  product  standards,  product  evaluation,  registration,  and  maintenance, 
set  by  a  series  of  committees  (Figure  7.3).^^  Another  element  was  the  use  of 
small  groups,  emphasized  since  1980,  which  met  once  or  more  a  month  to 
discuss   a    range  of  issues    related  to  productivity  and  quality,    as  well  as  work 
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conditions.  Managers  also  used  the  small  groups  to  supplement  formal  training 
required  of  new  company  employees.  As  part  of  the  second  High-Reliability 
Program,  initiated  in  1984,  the  Software  Division  also  began  working  extensively 
with  subsidiaries  and  contractors  to  establish  TQC  systems  similar  to  what 
existed  at  Numazu.^' 

Quantified  Managenient  System 

Fujitsu's  Numazu  Works  attempted  to  quantify  basic  measures  of 
performance  and  then  introduce  standardized  procedures  and  tools,  much  as 
conventional  factory  organizations  and  factory-like  software  facilities  have 
attempted.  Major  goals  were  to  reduce  individual  variability  and  dependency  on 
high-levels  of  experience  or  skill,  and  help  developers  "build  in"  quality  at  each 
phase,  rather  than  relying  on  inspection  at  the  end  of  the  process.^"  To 
achieve  these  ends,  Fujitsu  staff  in  inspection  and  quality  assurance  worked  on 
four  approaches.  First,  were  the  efforts  to  quantify  and  then  analyze 
information  on  project  progress  and  product  quality.  Second,  was  the 
introduction  of  methods  to  predict  error  occurrence  in  the  programming  phase 
and  institution  of  a  "management  by  objectives"  system  aimed  at  error 
correction.  Third,  to  determine  test  items,  was  the  use  of  statistical  "Design  of 
Experiment"  techniques,  often  referred  to  as  the  "Taguchi  method"  in  the  U.S. 
and  generally  applied  only  to  product  development  and  processing  of 
conventional  hard  products  such  as  automobiles.  Fourth,  was  an  attempt  to 
evaluate  quantitatively  the  concept  of   "user  friendliness"  of  software. 

Measuring  design  progress  was  problematic  mainly  because  the  most 
common  way  to  evaluate  schedules  was  to  compare  actual  progress,  such  as  the 
number  of  completed  modules,  or  in  Fujitsu's  case,  completed  "design  sheets" 
and  "work  items,"  with  estimates  made  prior  to  starting  work.   Accuracy  of  the 
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measure  thus  depended  on  the  accuracy  of  the  prediction,  which  managers  could 
not  fully  determine  until  completion  of  a  project.  To  evaluate  projects,  Fujitsu 
used  two  indices:  One  measured  quality,  based  on  points  received  in  reviews, 
and  another  quantity,  examining  how  well  predicted  amounts  of  work  fit  actual 
results.  These  data  also  helped  managers  define  tasks  in  small,  realistic 
segments,    and  minimize  estimation   errors. 

The  system  worked  as  followed:  In  the  planning  stage,  managers 
determined  work  items,  entered  these  on  work  item  sheets,  and  entered  them 
into  the  BSMS  data  base.  Work  items  were  segments  of  design  or  other 
activities  that  teams  could  finish  in  about  two  weeks.  The  Software  Division 
organized  projects,  in  groups,  and  each  group  leader  was  responsible  for  one 
work  item  at  a  time.  Each  project  member  had  to  fill  out  a  "review  trust 
sheet,"  as  well  as  undergo  reviews  from  several  other  people,  including  a  chief 
reviewer.  Reviewers  used  a  check-list  to  evaluate  work,  and  members  had  to 
make  changes  until  the  chief  reviewer  was  satisfied.  At  weekly  progress 
meetings,  managers  and  group  leaders  checked  the  progress  of  each  work  item. 
The  quality  index  compared  the  number  of  quality  points  received  in  reviews 
with  the  number  of  predicted  quality  points,  assigned  through  a  simple  scheme: 
Completion  of  materials  for  reviews  received  50  points;  completion  of  all 
reviews  and  changes  required  brought  100  points.  Projects  received  50  points 
for  completion  of  materials  for  reviews,  and  50  or  more  points  depending  on  the 
review  evaluations. 

Using  these  formulae,  Fujitsu  quantified  measures  for  each  project  member 
and  project,  including  product  quality.  In  addition,  Fujitsu  regularly  used 
statistical  regressions  and  factor  analysis  to  identify  probable  causes  of  errors, 
estimate  numbers  of  bugs  and  man-power  requirements,  and  test  the  accuracy  of 
estimates.     Progress  evaluations  still  depended  on  the  accuracy  of  the  predicted 
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values,  which  sometimes  were  far  from  actual  values.  Overall,  however,  Fujitsu 
managers  claimed  to  have  solved  the  major  problems  with  the  system  and 
reported  significant  improvements  in  progress  control  as  well  as  quality  (see  the 
discussion  on  performance  below). 

To  quantify  "ease  of  use,"  Fujitsu  employed  manual  reviews  and 
inspections,  and  validation  of  accuracy  by  surveying  users  through 
questionnaires.  Users  evaluated  products  on  specific  items,  which  numbered  as 
many  as  113  in  some  surveys,  using  simple  "yes"  or  "no"  responses  and  giving 
more  points  for  major  as  opposed  to  minor  items.  These  items  evaluated  basic 
product  characteristics  (product  performance,  reliability,  operability, 
compatibility,  coordination,  ease  of  maintenance,  quality  of  information,  price 
and  delivery),  design  quality  and  consistency  (defined  as  the  "degree  to  which 
software  targets  and  specifications  meet  user  needs,"  and  the  "degree  to  which 
the  finished  software  meets  the  design  targets  and  specifications"),  and 
sufficiency  and  attractiveness  ("the  extent  to  which  products  are  acceptable  to 
users").  The  surveys  indicated  that  users  grouped  these  features  into  three 
categories:  major  (such  as  friendliness,  efficiency,  understandability) , 
intermediate  (such  as  productivity,  ease  of  learning,  maintainability),  and  minor 
(such  as   syntax   flexibility,    speed  of  operation). 

DeskHlinq  and  Standardization  of  Testing 

Fujitsu's  objectives  in  testing  were  to  detect  65%  of  the  bugs  in  a  new 
program  by  the  end  of  the  coding  phase  review,  95%  by  the  end  of  system  test, 
and  as  many  of  the  remainder  as  possible  by  the  end  of  the  inspection 
process. ^^  A  problem  encountered  in  meeting  these  goals,  however,  was  that, 
as  in  the  design  of  any  complex  product  or  process,  large  programs  contained 
too    many    combinations     of    factors     and     conditions     to    test     completely. 
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Furthermore,  company  data  showed  significant  improvement  in  the  ability  of 
personnel  to  detect  errors  in  software  as  their  experience  increased,  with  a 
leveling  off  after  about  six  years.  As  a  result  of  these  observations,  Fujitsu 
managers  decided  to  employ  a  method  for  selecting  test  cases  that  less 
experienced  could  understand,  as  discussed  in  a  1987  article  by  an  engineer  in 
the  Quality  Assurance   Department: 

In  tests  involving  many  inspectors,  a  means  is  essential  to  standardize 
the  quality  of  testing  conducted  by  each  inspector,  but  there  is  a 
limit  as  to  the  extent  to  which  one  can  share  the  knowledge  and 
skill  through  training.  .  .  .  The  omission  of  test  cases  during  test  factor 
analysis  is  often  associated  with  problems  relating  to  the  scope  of 
knowledge  and  insight  of  the  testing  personnel....  The  omission  of 
test  cases  during  test  case  generation  is  often  caused  by  omissions  or 
careless  errors.  ..  .  [T]he  number  of  test  factors  [selected]  increases  in 
proportion  to  employed  years  up  to  6  years  and  stays  constant  after 
that.  Therefore,  to  improve  the  quality  of  test  factor  analysis  as  a 
whole,  it  is  a  significant  importance  [sic]  to  transfer  knowledge  to 
less  experienced  testing  personnel. ^^ 

Two  approaches  appeared  most  useful  in  capturing  and  transferring 
knowledge  regarding  software  testing.  One  was  to  develop  tools  that  automated 
as  much  of  the  testing  process  as  possible,  particularly  the  generation  of  initial 
tests  based  on  a  program's  external  specifications  or  input  characteristics.  Such 
tools  often  could  identify  critical  factors  that  were  the  source  of  most  errors  in 
a  program.  The  conventional  way  of  generating  initial  test  cases  was  to  use 
cause-effect    graphs,     but    these    required    a    great    deal    of    knowledge    to    use 
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effectively.  A  second  approach  was  to  create  a  data  base  on  test-factor  analysis 
methods  and  conditions,  complete  with  an  editing  support  function  to  help 
personnel  utilize  the  data  base  to  create  test  cases  for  new  programs.  As  part 
of  this  latter  technique  Fujitsu  introduced,  beginning  around  1980,  Design  of 
Experiments  methodology. 

The  Design  of  Experiments  techniques  relied  on  educated  guesses  of  where 
problems  were  likely  to  exist  (which  could  be  listed  for  easy  reference),  and 
then  specific  tests  selected  and  evaluated  relying  on  tables  of  "orthogonal 
arrays"  (statistically  independent  groups  of  factors) .  Fujitsu  claimed  these  made 
it  possible  to  control  the  number  of  combinations  that  existed  between  any  two 
factors  and  minimize  measurement  errors  and  other  conditions,  as  well  as 
identify  correctable  defects  more  quickly  than  conventional  techniques  such  as 
cause-effect  graphs.  In  fact,  Fujitsu  data  indicated  that  the  DE  methods  could 
actually  detect  5  to  10  times  or  more  the  number  of  errors  usually  found  with 
conventional   methods,    with   fewer  test  cases. ^' 

Tool  Support 

Similar  to  Hitachi,  Toshiba,  and  NEC,  in  the  mid-1970s,  Fujitsu  began 
introducing  numerous  computer-aided  tools  to  support  the  basic-software 
production  and  the  management  process  (Table  7.5).  Numazu  remained  the 
center  of  tool  R&D  until  the  mid-1980s,  when  Kamata  and  the  central  research 
facility,  Fujitsu  Laboratories,  began  studying  how  to  automate  system  design  and 
program  construction.  Perhaps  because  management  had  no  specific  "factory" 
plan,  as  at  Toshiba,  Numazu  developed  most  of  its  tools  for  discrete  use  rather 
than  as  parts  of  an  integrated  on-line  system,  although  standardized  methods 
accompanied  many  of  the  design-related  tools,  and  Numazu  had  the  capability 
for    data-base    links     among    TDPII,     ITS,     and    the    Dump    Transfer    system 
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(maintenance),  BSMS  and  TDP  II  (control),  and  GEM  and  PRISM  (program 
construction) .    -^ 

Two  basic  systems  were  BSMS,  described  earlier,  and  GEM  (Generalized 
Program  Editing  and  Management  Facilities),  a  library-management  and  data- 
collection  tools  that  automatically  generated  graphic  reports,  for  groups  and 
individuals,  on  productivity  (lines  of  code  developed) ,  progress  status  (by  month 
and  week),  and  quality  (bug  levels  per  module).  The  library  functions  included 
version  control  of  modules  and  completed  programs,  as  well  as  compressed  data 
to   reduce  the  volume  of  stored  files.    "^ 

Another  important  tool  and  methodology  set  was  YACII  (Yet  Another 
Control  chart),  which  Fujitsu  used  for  functional  design,  and  VPS  (YACII 
Programming  System),  a  tool  developed  at  Kamata  that  automatically  generated 
code  from  the  flow  charts.  Fujitsu  introduced  the  YAC  charts  in  1980, 
modeling  them  after  similar  diagrams  used  at  NTT.  The  current  version, 
introduced  in  1987  along  with  YPS,  contained  an  editor,  compiler,  debugger,  and 
documenter,  and  received  inputs  in  structured  but  conversational  Japanese  on 
work  stations.  A  host  computer  translated  the  inputs  into  machine-readable 
YACII  charts  and  then  executable  "bug-free"  code  in  C,  Fortran,  Cobol,  or  LDL 
(Logic  Design  Language),  a  language  based  on  C  for  basic-software  design  that 
Fujitsu  developed  to  use  with  YACII  charts.    (LDL  replaced  an  earlier  in-house 

language,  System  Programming  Language  or  SPL,  which  Fujitsu  had  based  on 
PL/I). 34 

As  discussed  with  reference  to  similar  tool  sets  at  Hitachi  (PAD  and  PAD 
code  generators)  and  NEC  (SPD  and  DECA),  the  combination  of  YACII  and  YPS 
enhanced  productivity  in  nearly  all  phases  of  development,  at  least  after  high- 
level  design.  They  helped  eliminate  poorly  structured  programs  by  supporting 
top-down,  structured  design  through  graphical  and  text  representations.     They 
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practically  eliminated  coding  errors,  since  the  designs  were  executable.  They 
facilitated  reuse  of  whole  programs,  program  parts,  or  edited  portions  of  a 
program  at  the  design-specification  level  and  thus  across  different  computer 
languages  or  architectures.  They  included  executors,  test-coverage  evaluators, 
and  debuggers  that  executed  the  charts,  and  helped  developers  evaluate  the 
comprehensiveness  of  test  cases,  collect  and  analyze  data,  and  debug  programs. 
The  tools  also  facilitated  maintenance,  both  fixing  problems  and  adding 
enhancements,  first  by  minimizing  coding  errors  and  then  by  presenting  designs 
in  standard  formats  that  were  relatively  simple  for  third  parties  to  understand. 
A  document  generator  also  produced  detailed  specifications  automatically  from 
the  design  charts.  in  addition,  YPS  and  other  systems  included  reverse 
generators  that  produced  design  charts  from  source  code;  developers  could  then 
edit  the  charts  more  easily  than  source  code  as  well  as  store  the  charts  in  a 
data  base  for  later  retrieval. ^^ 

Performance  Improvement 

Fujitsu  did  not  publish  or  make  available  much  performance  data  for  basic 
software,  although  information  available  indicated  steady  gains  in  the  decade 
after  1975  in  quality  (reliability),  productivity  (development  costs),  and  project 
schedule  control  (lateness).  The  major  products  at  Numazu,  mainframe 
operating  systems  and  related  components,  were  lengthy  and  complex,  totalling 
as  much  as  2  million  lines  of  code,  excluding  data-base  software,  with  major 
individual  components  running  from  about  100,000  to  800,000  lines  of  C  and  LDL 
source  code   (without  comments). ^° 

For  all  code  in  the  field  (new  code  plus  maintained  software),  between 
1977  and  1979,  bugs  reported  by  users  dropped  by  one-third,  and  then  another 
one-third    between     1979    and    1982     (Table    7.6).        By    1985,     bug    levels    for 
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outstanding  code  had  fallen  to  practically  zero  (0.01  and  below).  Fujitsu  would 
not  allow  the  publication  of  data  for  newly  written  code,  but  this  showed 
similar  gains.  Bugs  per  TOGO  lines  of  new  code  reported  by  users  (generally 
about  10  times  the  level  for  all  code)  fell  four-fold  between  1980  and  1981 
alone.  Improvement  since  1981  leveled  off,  as  bugs  dropped  to  approximately 
0.1  and  below,  although  this  level  was  already  excellent  by  most  standards  and 
the  averages    reported  for  Japan   and  the  U.S.    (see  Appendix    B)  . 

Fujitsu  data  also  suggested  that  the  review  procedures  instituted  after  the 
late  1970s  helped  create  these  low  bug  levels  and,  especially,  cut  down  the 
number  of  defects  in  design.  For  example,  in  1977,  Numazu  personnel  detected 
approximately  85%  of  bugs  found  through  testing  and  15%  through  reviews  of 
source  code  (coding  phase  review).  Design-sheet  reviews,  instituted  in  1978, 
found  more  bugs  and  gradually  became  the  major  method  for  bug  detection, 
rising   from  5%  to  approximately  40%  as   early  as    1982. 

Productivity  was  another  area  where  management  would  not  publish  data, 
in  part  because  of  a  lack  of  standardization,  until  the  mid-1980s,  in  how 
projects  counted  these  numbers.  Current  measures  of  productivity  included  lines 
of  code  (steps)  produced  per  man-month,  number  of  documents  per  man-month, 
total  development  costs  per  1000  lines,  machine  time,  and  pages  of 
documentation  per  1000  lines  of  code.*^'  According  to  these  measures,  Numazu 
appeared  to  experience  major  improvements  in  productivity  between  1975  and 
1978,  corresponding  to  new  procedures  for  project  management  and  control 
introduced,  and  somewhat  less  dramatic  but  still  significant  improvements  during 
the  mid-1980s,  following  new  efforts  in  quality  control  and  centralization  of 
development  efforts   at  Numazu. 

In  addition  to  apparent  rises  in  quality  and  productivity,  Fujitsu's 
emphasis,    dating    back    to    the    early    1970s,    on    product    and    project    control 
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gradually  led  to  significant  progress  in  scheduling  accuracy.  Most  projects 
came  in  late  in  the  early  days  of  programming,  with  "late"  defined  as  reaching 
the  Inspection  Department  after  the  scheduled  time.  Even  during  the  latter 
half  of  the  1970s,  about  40%  of  projects  typically  fell  behind  schedule.  By  the 
early  1980s,  however,  Numazu  had  reduced  this  to  about  15%,  a  level  comparable 
to  Hitachi.  Most  delays  that  remained  came  in  the  transition  from  functional 
design  to  coding,  phases  that  continued  to  be  difficult  to  estimate  accurately, 
due  to   variations    in   people  and   product   requirements."^" 


APPLICATIONS-SOFTWARE  DEVELOPMENT 
Systems  Enaineering  Group 

Fujitsu's  decision  to  create  a  large  organization  for  custom  programming, 
stemmed  from  the  same  need  SDC,  Hitachi,  Toshiba,  and  NEC  encountered  in 
their  applications  areas:  to  produce  a  variety  of  nominally  different  programs 
more  efficiently--  that  is,  with  improved  levels  of  productivity,  project  control, 
and  quality.  In  the  early  1960s,  Fujitsu  customers  performed  most  of  their  own 
programming,  with  assistance  from  a  Service  Department  Fujitsu  set  up  within 
the  Computer  Division  in  1963.  Several  large  orders  for  on-line  banking, 
securities,  and  data-processing  systems  to  the  creation  of  a  Systems  Department 
in  1964,  the  forerunner  of  the  Systems  Engineering  Group,  which  built  programs 
for  and  with   customers    (Table  7.7). 

Continued  increases  in  sales  of  Fujitsu's  230  series  computers  brought  more 
demand  for  customized  applications  software,  prompting  management  to  establish 
the  Information  Processing  System  Laboratory  in  Kamata,  Tokyo,  during  1970. 
The  Laboratory,  with  an  initial  staff  of  700,  allowed  Fujitsu  to  centralize 
training  operations  as  well  as  customized  programming  for  business,  engineering, 
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and  scientific  applications.  The  M-series  computers,  however,  brought  more  new 
orders  for  programs  that  were  themselves  growing  in  size  and  complexity, 
prompting  management  to  organize  a  Systems  Engineering  Group  in  the  later 
1970s  that  included  a  Software  Factory  as  well  as  numerous  software 
subsidiaries   and   subcontractors.    ^ 

As  of  1988,  the  Systems  Engineering  Group  consisted  of  three  major  areas 
(Figure  7.4):  The  Common  Technology  Area  included  the  SE  (System 
Engineering)  Technical  Support  Center,  which  housed  the  Software  Factory 
Department  and  its  1500  programmers  as  well  as  other  sections  such  as  for 
information  support  (product  information  for  customers),  technology  transfer, 
office  systems  engineering,  and  the  SIGMA  project;  the  Applications  Software 
Planning  Division,  which  dealt  mainly  with  packages;  and  a  research  institute. 
Industry-related  departments  performed  system  engineering  for  companies  in 
finance,  insurance,  securities,  and  manufacturing  and  distribution,  as  well  as  for 
NTT,  scientific  and  technical  applications,  and  government  users.  The  third 
area  consisted  of  functionally  specialized  departments,  such  as  for  management 
information  systems,  "value-added  networks"  for  different  on-line  services, 
personal-computer  systems,    and   new  telecommunication   firms    (NCCs). 

Evolution  of  the  Factory  Strategy  and  Structure 

Several  specific  reasons  lay  behind  the  decision  to  create  a  software 
factory  in  1979  and  to  structure  the  facility  in  the  manner  Fujitsu  did.  First, 
was  a  desire  among  managers  to  increase  the  level  of  centralization  of  similar 
work,  initially  for  program  conversion  and  then  for  new  development.  Second 
was  to  separate  high-level  design  (system  engineering)  from  product 
construction  and  then,  third,  take  advantage  of  progress  in  the  field  of 
software  engineering  by  standardizing  work  around  good  methods  and  tools  for 
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all  projects.  Fourth  was  a  desire  to  improve  Fujitsu's  technical  and  managerial 
infrastructure  for  controlling  large,  complex  projects,  especially  those  involving 
large  amounts  of  subcontracting,  which  required  more  formal  methods  of 
coordination  and  control  to  meet  budgets,  schedules,  and  quality  objectives. 
The  overall  intention  was  to  build  a  permanent  organization  that  would  allow 
more  programmers  and  managers  to  benefit  from  knowledge  accumulating  within 
Fujitsu  regarding  development  tools  and  methods,  standardization,  programming 
environments,  and  product  designs.  Managers  expected  their  concept  of  the 
factory  approach  to  bring  improvements  in  productivity,  project  management, 
quality  control,    and   software   reuse. ^ 

Fujitsu  experienced  both  successes  and  disappointments  with  its  approach. 
Management  experimented  with  a  centralized  organization  by  setting  up  a 
Software  Conversion  Factory  Department  in  1977,  with  approximately  TOO 
personnel.  This  modified  the  huge  number  of  programs  customers  wanted  to  run 
on  the  new  M-series  machines,  which  were  not  compatible  with  Fujitsu's 
previous  architectures,  as  well  as  converted  IBM  and  other  software  to  run  on 
Fujitsu  hardware.  Management  believed  that  conversion  work  was  fairly 
straightforward  and  that  centralization  of  personnel  and  equipment,  as  well  as 
methodological  standardization,  would  make  the  tasks  easier  to  manage  and 
result  in  higher  productivity.  The  idea  worked  well  enough  so  that  Mitsugi, 
after  he  became  head  of  the  System  Engineering  Group,  decided  to  expand  the 
operations  of  the  factory  to  include  program  construction.  He  then  added 
another  200  personnel  and  charged  them  with  turning  requirements  specifications 
received  from  system  engineers  into  code.  Prior  to  this,  Fujitsu  had  managed 
system  engineering  and  program  construction  in  integrated  projects,  with  no 
separation  of  these  two  functions. 

Mitsugi    admitted,     however,     that    his     "original    factory    idea,     due    to 
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inexperience,  went  too  far."  Much  like  SDC  experienced,  managers  found  that 
many  projects  depended  on  close  interactions  with  customers  and  knowledge  of 
very  different  requirements.  Or  writing  the  applications  program  sometimes 
required  access  to  specialized  or  proprietary  information  that  some  customers, 
for  security  reasons,  preferred  not  to  give  Fujitsu  personnel  unless  they  worked 
at  the  customers'  own  sites.  There  were  other  occasions  where  Fujitsu  needed 
to  provide  programming  services  locally  at  various  locations  around  Japan,  again 
departing  from  a  centralized  factory  model.  In  addition,  as  Fujitsu  improved 
the  tools  and  reuse  data  bases  available  in  the  factory,  less-experienced 
programmers   became  better  able  to  build   complete  systems. 

As  a  result  of  recognizing  that  different  projects  had  different  optimal 
processes  for  project  management,  Fujitsu  made  several  changes  in  how  it 
divided  or  apportioned  work.  One  change  was  to  expand  the  scope  of  the 
factory  departments  to  do  more  detailed  design  for  some  projects  and  eventually 
to  do  system  design,  again,  for  some  projects  where  it  was  difficult  or 
unnecessary  to  separate  functions,  either  for  logistical  reasons  or  because 
factory  departments  had  the  necessary  expertise  to  build  a  system.  Another 
strategic  move  was  to  encourage  system  engineers,  who  initially  did  surveys  and 
project  planning,  system  design,  and  program  structural  design,  not  merely  to 
let  factory  teams  do  more  of  the  product  construction,  but  to  leverage  their 
expertise  more  widely  by  writing  software  packages  that  would  cover  a  range  of 
user  needs.  Packages  that  teams  could  use  in  custom  programs  thus  eliminated 
the  need  to  write  a  lot  of  code  from  scratch.  In  addition,  to  spread  the  burden 
of  programming  more  widely,  Fujitsu  management  in  the  1980s  decided  to 
establish  or  work  with  many  more  software  subsidiaries  and  software  houses 
around  Japan,  as  well  as  sell  or  lease  methodologies  and  tools  to  customers  (see 
Table  7.7).'^'^ 
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The  methods  and  tools  used  in  Fujitsu's  factory,  like  in  other  Japanese 
software  factories,  were  also  continually  evolving  in  response  to  changes  in 
software  technology  and  customer  needs.  An  important  stimulus  were  orders 
Fujitsu  received  in  the  mid-1980s  from  Japanese  banks  for  on-line  software 
systems  requiring  several  million  lines  of  code.  To  manage  these  projects, 
Fujitsu  embarked  on  another  effort  to  upgrade  tools  and  techniques  for  project 
control,  design  notation  and  support,  automatic  programming,  testing  support, 
and  quality  assurance.  Fujitsu  packaged  and  began  leasing  these  tools  and 
techniques  in  1987  as  SDAS  (Systems  Development  Architecture  and  Support 
Facilities),  replacing  SDSS  (Software  Development  Support  System)  and  SDEM 
(Software  Development  Engineering  Methodology),  the  original  factory  standards 
adopted   in   1977-1978  and   leased  to  customers   since  1980. 

Process  Standardization 

SDEM  consisted  of  standardized  development  and  control  procedures 
extending  from  requirements  definition  to  system  maintenance  and  project 
management. ^-^  The  System  Engineering  Group  had  guidelines  prior  to  1977,  but 
management  defined  them  vaguely  and  weakly  enforced  them.  Development  was 
very  much  in  a  "craft"  mode,  with  programs  more  the  property  of  individuals 
than  the  product  of  an  organization.  Documentation  and  standardization  were  so 
lacking  that,  as  the  engineers  who  developed  SDEM  and  SDSS  recalled,  it  was 
difficult  to  understand  programs  other  personnel  wrote: 

We  had  software  development  standards  before  SDEM  and  SDSS  were 
developed  but  the  standards  had  no  clear  definition  of  the 
development  phases.  This  lack  of  definition  resulted  in  so  much 
freedom     that     software     systems     often     became    the     products     of 
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individuals.  It  was  not  easy  for  a  person  who  had  not  designed  a 
program  to  understand  how  it  worked.  To  improve  on  this  situation, 
we  concluded  that  clear,  reasonable  definitions  of  the  developing 
phases  and  activities  were  required.  The  kinds  of  tasks  performed 
during  each   activity  also  needed   standardization.^ 

A  software-engineering  team  Fujitsu  established  in  1976  to  study  this 
problem  considered  two  options  to  structure  the  development  process: 
improvement  and  standardization  of  procedures,  techniques,  and  other  elements 
that  made  up  the  programming  environment;  and  automatic  program  generation, 
relying  on  standardized  formats  for  specifying  user  requirements  and  "state-of- 
the-art"  tools.  Due  to  the  still-emerging  state  of  program  generation,  they 
decided  to  begin  with  introducing  standards  and  take  up  program  generation 
later.  Before  looking  more  deeply  into  automation,  the  team  also  realized  they 
had  to  establish  a  formal  methodology: 

There  are  two  approaches  to  software  engineering.  One  approach  is 
to  upgrade  current  development  methods  by  standardizing  development 
procedures  and  by  improving  both  programming  techniques  and  the 
development  environment.  In  the  other  approach,  programs  are 
directly  generated  using  formal  specifications  of  user  requirements, 
and  this  approach  involves  the  application  program  generator  or 
automatic  programming.  The  latter  approach  is  one  way  of 
accomplishing  our  ultimate  goal  of  software  engineering,  and  if  we 
narrow  the  applied  field  this  approach  is  feasible.  However,  it  is 
very  difficult  to  realize  these  latter  technologies  at  the  present  state 
of  the  art,  if  we  apply  them  generally.  .  .  .  Therefore,  we  addressed  the 
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following  items  based  on  the  evolutionary  approach:  1)  clarification  of 
software  development  methods  and  standardization  for  development 
activities,  2)  utilization  of  tools  to  computerize  development 
activities. 

We  developed  SDEM  around  the  first  item.  For  the  second,  we 
developed  SDSS  as  a  set  of  tools  to  support  the  phases  after  system 
design.  .  .  .  Our  basic  attitude  toward  software  development  is  that  it  is 
more  desirable  to  first  clarify  software  development  methods  and  a 
software  development  system,  then  to  approach  these  problems  and 
solutions  rationally  and  systematically,  depending  heavily  on  feedback 
from  the  actual   system  developers. ^^ 

After  studying  current  practices  in  software  engineering,  the  team  wrote 
four  manuals  that  set  down  the  SDEM  methodology.  The  SDEM  Concept  Manual 
outlined  basic  standards  and  the  overall  development  approach.  The  SDEM 
Standards  Reference  Card  listed  specific  procedures  and  work  items  for  each 
development  phase  and  project-team  member.  The  Detailed  SDEM  Standards 
Manual  presented  more  details  of  each  work  item  and  related  documents,  with 
examples.  The  SDEM  Introduction  and  Application  Manual  explained  basic 
management  techniques  and  guidelines  for  introducing  and  using  the  SDEM 
system.  The  development  process  SDEM  defined  divided  the  life  cycle  into  6 
stages  and  12  specific  phases,  from  survey  and  planning  through  maintenance 
and  evaluation.  These  included  a  series  of  work  categories  and  specific  work 
steps,  as  displayed  in  Figure  7.6.  The  initial  SDEM  standards,  and  later 
modifications,  thus  covered  software  products,  development  technology,  and 
management,    including  procedures  for  modularization  as  well  as  construction  of 

36  Fujitsu 


packages  and  reusable  design  patterns  (paradigms) .  For  programming,  SDEM  set 
standards  for  coding  (primarily  in  COBOL  and  FORTRAN).  For  design,  it 
specified  methods  and  how  to  write  documentation.  SDEM  also  provided  review 
guidelines  and  checklists,  testing  procedures,  and  standards  for  estimating  times 
for  project  management,  although  it  should  be  noted  that  management  tailored 
standards,  methods,  and  tools,  and  performance  expectations,  to  accommodate 
programs  of  different  types   and   sizes. 

Just  as  SDEM  resembled  procedures  set  down  in  manuals  at  other  Japanese 
and  U.S.  firms,  Fujitsu's  engineering  team  cited  benefits  of  process  standards 
noted  earlier  at  Hitachi,  Toshiba,  and  NEC:  They  believed  standardization 
would  make  it  possible  to  even  out  the  quality  of  products,  facilitate 
maintenance,  reduce  the  dependency  of  the  development  process  on  individual 
experience,  ease  tool  introduction,  and  simplify  management  control. ^^  While 
Fujitsu  appeared  to  experience  these  benefits,  another  objective  of  SDEM  was 
to  facilitate  the  separation  of  system  design  from  program  design  as  well  as 
improve  the  "flexibility"  (portability  or  reusability)  of  designs.  As  noted  earlier, 
dividing  labor  proved  more  problematic  than  managers  at  first  realized,  although 
standardized  techniques,  in  combination  with  management  objectives  and  tool 
support,  seemed  to  enhance  design  portability  and  reuse  significantly.  Managers 
also  claimed  that  use  of  SDEM  and  factory-support  tools  in  all  phases  minimized 
misunderstandings  and  errors  that  normally  occurred  in   software  development. 

System  designs  consisted  of  exterior  specifications  and  logical  designs  that 
did  not  rely  on  specific  machines  (computers)  or  languages,  whereas  program 
designs  consisted  of  the  physical  program,  which  was  machine  and  language 
dependent. ^^  Developing  system  designs  separately  from  the  actual  program 
created  a  risk  that  the  entire  implementation  effort  might  be  wasted  if  a 
finished  program  did  not  meet  customer  requirements.     But  while  Fujitsu  clearly 
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encountered  problems  of  this  sort,  managers  found  two  solutions:  One  was  to 
promote  extensive  interaction  between  system  engineers  and  programmers  in 
determining  the  accuracy  and  meaning  of  design  documents.  Another  was  to 
expand  the  activities  of  factory  personnel  into  design,  program  construction, 
testing,    and  maintenance. 

Process  and  Work- Flow  Management 

Since  unique  knowledge  was  often  essential  for  accurate  system  design, 
Fujitsu  initially  established  specialized  system-engineering  departments  outside 
the  software  factory  focusing  on  manufacturing,  distribution,  financial  systems, 
government  systems,  and  scientific  and  engineering  programs.  The  SE 
departments  generally  handed  designs  to  programming  sections  in  the  software 
factory,  which  built  about  20%  of  new  applications  done  in  the  System 
Engineering  Group  as  well  as  handled  about  75%  of  all  program  conversion,  or 
to  subsidiaries  and  affiliated  software  houses,  which  built  most  of  the  remaining 
work  organized,  consisting  of  approximately  800  small  projects  per  year.  To 
manage  projects,  Fujitsu  designated  both  a  chief  system  engineer  and  a  chief 
programmer,  and  gave  system  engineers  the  main  responsibility  for  dealing  with 
customers  and  delivering  systems  that  correctly  met  customer  specifications.'*' 

Because  system  engineers  were  responsible  for  code  they  did  not  write  or 
test  at  all  levels  themselves,  program  development  required  cooperation  and 
trust  among  project  members,  as  well  as  standardization  practices.  As  noted, 
however,  Fujitsu's  original  approach  --  dividing  all  system  development  from 
system  construction  --  did  not  work  smoothly  in  all  cases,  prompting  managers 
to  change  the  way  they  organized  product  development,  at  least  for  some 
projects.  Figure  7.7  describes  how  Fujitsu  expanded  these  patterns  in  the 
software  factory  between   1979  and   1988. 
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Under  the  first  pattern,  factory  personnel,  organized  into  teams  of  7  or  8 
programmers,  performed  module  design,  coding,  and  testing  for  4  or  5  system 
engineers  outside  the  factory.  The  system  engineers  took  charge  of  planning, 
system  design,  program-structure  design,  and  integration  and  system  testing. 
The  standard  process  required  them  to  write  design  specifications  in  a  particular 
format  using  conversational  language  (Japanese  mainly),  and  to  provide 
input/output  diagrams  and  mathematical  equations,  as  necessary,  to  minimize  the 
amount  of  skill  required  of  the  factory  personnel.  Managers  encouraged 
programmers  who  did  not  understand  part  of  a  design  document  to  call  the 
responsible  system  engineer  and  discuss  the  problem.  When  programmers 
finished  a  part  of  a  system,  they  would  send  it  back  to  the  system  engineers, 
who  would  check  it  with  the  customer.  Designers  and  programmers  then 
conducted  system  tests  together  at  the  customer  site.  System  engineers  in  the 
field  then  might  perform  operation  tests  with  customers.     Fujitsu  provided  some 

assistance  In  maintenance  as  well,   although  generally  took  care  of  this  on  their 
own.  48 

Most  projects  in  the  first  few  years  of  the  factory  were  of  small  to 
medium  size,  running  from  10,000  to  a  few  hundred  thousand  lines  of  code  and 
consuming  from  a  few  months  to  one  year.  Where  requirements  were  relatively 
well  understood,  dividing  labor  on  these  projects  worked  relatively  smoothly. 
As  programs  grew  in  complexity,  newness,  and  size,  frequently  to  about  1 
million  lines  of  code  and  up  to  years  for  completion,  Fujitsu  instituted  a  second 
pattern  around  1982.  This  required  the  project  teams  within  the  factory  to 
complete  more  work  --  system  design,  program  structure  design,  and  integration 
and   system  test,    as  well   as  module  design,    coding,    and  testing. 

As  factory  personnel  became  more  adept  at  system  development, 
particularly   with    the    support   of    a    series    of   computer-aided    tools,    managers 
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adopted  a  third  pattern  circa  1985.  This  called  for  factory  personnel  to  design, 
build,  and  test  complete  systems  --  including  the  initial  "survey"  (customer 
consultation)  and  project  planning,  as  well  as  operational  test,  evaluation,  and 
maintenance.  Some  of  these  projects  consisted  of  new  banking  and  value- 
added-tax  calculation  systems  that  regularly  exceeded  a  million  lines  of  code 
and   lasted  two  or  three  years. ^^ 

Another  issue  for  managers  in  the  System  Engineering  Group  when  they 
made  project  assignments  was  where  to  send  work  --  to  the  factory  or  to 
subsidiaries  or  software  houses.  To  some  extent,  this  was  a  simple  capacity 
decision.  If  all  departments  in  the  factory  were  busy,  management  had  to  send 
work  elsewhere.  However,  Fujitsu  did  have  some  guidelines.  In  general, 
management  tried  to  give  the  factory  big  projects  where  extensive  tool  or 
computer  support,  as  well  as  careful  standardization  of  methods,  tools,  and 
procedures,  were  particularly  important,  and  where  the  factory  tools  and 
methods  were  appropriate.  This  latter  point  meant  that  managers  tended  to  put 
work  into  the  factory  that  was  large-scale  and  similar  to  previous  projects  done 
in  the  factory  and  that  could  take  advantage  of  existing  development 
technology. 

Especially  for  large  projects,  in  1984  Fujitsu  introduced  what  management 
called  the  "on-line  SDEM  system.  This  allowed  up  to  a  thousand  people  to 
work  on  a  single  project  simultaneously,  with  200  to  300  terminals  connected  to 
a  single  mainframe.  (The  Kamata  factory  maintained  about  one  terminal  or 
work  station  for  every  1.5  employees,  more  than  twice  the  ratio  at  Toshiba.) 
Some  projects  done  in  the  factory  might  use  as  many  as  6  mainframes  and 
involve  a  thousand  personnel  over  a  period  of  one  or  two  years.  Dedicated 
tools  that  ran  off  these  mainframes  and  data  bases  also  simplified  product 
development.      For  products  that  required  special  experience  in  the  application 
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even  to  do  coding,  such  as  scientific,  space,  and  nuclear-plant  software,  system 
engineers  generally  built  the  entire  programs  themselves,  without  handing  off 
specifications  to  the  Software  Factory.  These  types  of  specialized  programs 
accounted  for  10%  to  20%  of  the  orders   in  the  System   Engineering  Group. ^^ 

Another  guideline  was  to  try  to  give  small  "one-time"  projects  to  a 
subsidiary  or  software  house.  As  noted,  these  companies,  which  generally 
worked  on  a  long-term  basis  with  Fujitsu,  provided  1300  of  the  1500  personnel 
in  the  Software  Factory  as  well  as  manpower  for  additional  projects.  They 
allowed  Fujitsu  to  accommodate  different  types  of  work  as  well  as  meet  demand 
peaks  without  adding  too  many  full-time  (and  higher  paid)  employees  to  the 
ranks  of  its  permanent  work  force,  although  another  reason  for  using  outside 
personnel  originally  was  a  shortage  of  new  recruits.  Fujitsu  also  sometimes 
used  software  houses  as  sources  of  personnel  to  help  in  coding  for  large 
projects  that  were  running  late.  As  at  other  Japanese  software  factories, 
Fujitsu  managers  claimed  they  were  able  to  add  people  without  delaying  projects 
further  because  of  the  standardized  methods  and  tools,  and  training,  even  of 
subcontractors'   personnel. 

Training  and  Career  Paths 

While  most  employees  in  the  Kamata  Software  Factory  were  college 
graduates,  and  usually  had  good  backgrounds  in  science  or  mathematics,  as  at 
Hitachi,  Toshiba,  and  NEC,  new  employees  generally  had  no  computer 
engineering  or  software  training. ^^  While  this  required  Fujitsu  to  invest 
heavily  in  training,  as  in  other  cases,  management  was  able  to  teach 
programmers  and  system  engineers  how  to  use  methods,  procedures,  and  tools 
certified  as  standards  in  the  Software  Factory  or  the  System  Engineering  Group. 

Fujitsu  began  some  general  education  with  the  establishment  of  the  Kamata 
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Laboratory  in  1970,  though  it  was  several  years  before  management  determined 
standards  for  applications  development  and  coordinated  these  with  training. 
One  landmark  was  the  introduction  of  seminars  to  teach  the  SDEM  standards  in 
1977.  Fujitsu  followed  these  with  periodic  workshops  for  project  managers  and 
a  lengthier  education  program  for  new  employees,  in  addition  to  courses  for 
customers.  As  an  example  of  the  scale  and  breakdown  of  training,  Fujitsu  in 
1987  offered  courses  on  computers  and  software  education  to  over  89,000  people. 
The  largest  group,  approximately  57,000,  were  employees  of  Fujitsu's  customers. 
Of  the  remaining,  12,000  were  Fujitsu  employees,  13,000  workers  from  system- 
engineering  subsidiaries  or  affiliates,  and  4,000  workers  from  dealers  and 
software  houses. 

Like  the  other  Japanese  firms  discussed,  Fujitsu  coordinated  its  formal 
education  program  with  career  paths.  New  employees  were  trainees  for  their 
entire  first  year  and  attended  full-time  classes  for  three  months,  learning 
Assembler,  COBOL,  machine  1/0,  and  other  areas  of  basic  programming  and 
computer  architectures.  After  the  classes,  training  continued  on-the-job  through 
coding  simple  programs  for  commercial  customized  systems  and  through  another 
2  or  3  days  of  additional  instruction  every  month  or  two.  Until  they  became 
managers,  employees  continued  to  receive  about  8  days  of  training  a  year  in 
workshops,  in  addition  to  self-study  materials  and  quality-circle  activities 
(Figure  7.5).  This  education  included  topics  such  as  writing  and  speaking, 
system  design,  project  management,  contracts  and  law,  network  design  and 
requirements  analysis,    and  product-specific  information. 

New  employees  usually  did  coding  for  2  or  3  years  and  then  moved  on  to 
module  design  and  structural  design.  For  education  planning,  rather  than  for 
project  management,  as  at  Hitachi,  Fujitsu  also  assigned  skill-level  ranks  to 
personnel,   from   1    to  5,    based  on   self-evaluations  as  well  as  some  testing  with 
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courses.  After  about  3  years  of  work,  depending  on  an  individual's  ability,  a 
programmer  might  become  a  system  engineer  or  move  into  project  management 
and  support.  Project  management  and  support  functions  included  revising 
standard  times,  carrying  out  quality  assurance  measures,  proposing  means  for 
quality  and  productivity  improvement,  or  developing  and  evaluating  new  tools 
and  methods. 

Fujitsu  also  granted  the  rank  of  senior  systems  engineer  to  employees  with 
from  9  to  13  years  experience,  depending  on  whether  they  were  high  school  or 
college  graduates.  These  engineers  specialized  in  application  areas,  in  contrast 
to  factory  programmers  (although  managers  tended  to  assign  programmers  to 
projects  similar  to  what  they  had  done  in  the  past).  To  improve  its  training  of 
system  engineers  as  well  as  ability  to  provide  service  to  customers,  in  1986 
Fujitsu  also  established  the  Fujitsu  Research  Institute  for  Advanced  Information 
Systems  and  Economics.  This  facility,  staffed  with  30  experienced  managers  and 
70  experienced  system  engineers,  trained  Fujitsu  personnel  in  system 
consultation  while  assisting  customers  in  system  planning  and  problem  solving. ^^ 

Quality  Control 

SDEM  procedures  for  quality  control  were  similar  to  those  used  at  Numazu, 
although  the  System  Engineering  Group  allowed  projects  more  autonomy. 
Management  was  very  slow  to  separate  quality  control  from  project  management 
and  established  an  independent  inspection  department  only  in  1987,  and  then 
primarily  to  check  work  done  at  subcontractors.  Nonetheless,  Kamata  had  a 
formal  process  that  seemed  effective  for  checking  work  in  progress  and 
providing  feedback  on  analyzed  data  to  designers,  programmers,  project 
managers,  and  staff  responsible  for  work  standards.  The  factory,  like  Numazu, 
was  also  automating  more  aspects  of  quality  control,    such  as  by  devising  tools 
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to  check  programs  against  specified  coding  or  design   rules,   and  collect  various 
quality  data  for  later  analysis. 

Another  difference  from  Numazu  was  that,  rather  than  having  management 
set  quality  objectives,  projects  managers  tended  to  negotiate  with  customers  to 
determine  quality  targets  --  "maximum  allowable  number  of  errors  per  1000 
statements."  This  was  common  for  application-s  programming,  as  seen  at 
Toshiba.  Fujitsu  also  required  project  members  to  propose  solutions  to  quality 
problems.  If  early  tests  indicated  bug  levels  were  above  target,  the  developers 
had  to  validate  the  target  levels  and  then  describe  the  countermeasures  they 
planned  to  use.  For  example,  to  decrease  "building-in"  bugs,  common 
countermeasures  were  to  improve  standardization  controls,  reuse  program  parts 
or  paradigm  designs,  generate  more  code  automatically,  or  make  greater  use  of 
data  dictionaries.  To  increase  "bug  detection,"  projects  relied  on  design 
reviews,    source  code  checks,    test-coverage  tools,    and   verification   tools. ^ 

Computer- Aided  Tools 

Fujitsu  was  distinctive  for  extensive  investment  in  support  tools  for  all 
phases  of  product  development  but  especially  automating  aspects  of  program 
design  and  coding  and  supporting  the  reuse  of  designs  and  code  in  the  form  of 
library  routines  and  registered  packages,  which  served  as  program  parts  for 
semi-customized  systems.  Kamata,  primarily  the  SE  Technical  Support  Center, 
was  the  main  locus  of  this  research,  although  Fujitsu's  central  research 
laboratories  also  provided  assistance  and  Kamata  sometimes  imported  tools  from 
Numazu   (as  Numazu   sometimes  did  from   Kamata). 

Kamata's  first  effort  at  producing  an  integrated  tool  set  was  SDSS 
(Software  Development  Support  System)  in  the  late  1970s.  This  automated  or 
mechanized    aspects    of    documentation    compilation,     file    editing,     and    project 
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management,  relying  on  a  project  library  for  FORTRAN  source  programs, 
designs,  test  data,  documentation;  a  module  description  language  and  analyzer 
containing  information  such  as  the  name  and  module  function,  interfaces  with 
other  modules,  and  syntax;  and  test-support  tools  for  module  test,  results 
analysis,  module  path  tracing,  and  test-case  selection.  Although  Fujitsu  gradually 
supplanted  SDSS,   the  tool  established  general  objectives  for  future  research. 

One  of  the  first  tasks  was  to  build  a  system  like  SDSS  that  handled 
languages  other  than  FORTRAN,  since  most  business  applications  were  in 
COBOL.  Another  challenge  was  to  improve  the  module  description  language  so 
it  could  describe  more  complicated  data  structures  and  support  the  beginning  of 
program  design,  rather  than  module  definition  only.  Other  objectives  for  long- 
term  tool  research  were  to  develop  program-generation  and  reuse  support,  as 
well   as   systems  to  generate  maintenance  documents  from   source  code."*^ 

Fujitsu  accomplished  these  goals  and  more.  Particularly  important  tools 
were  the  combination  of  YAC  flow-charts  and  YPS,  developed  in  the  System 
Engineering  Group  (and  imported  by  Numazu),  to  facilitate  program  design, 
editing,  code  generation,  and  reuse;  GEM,  also  described  earlier  and  imported 
from  Numazu,  which  served  as  a  program  library  system  and  production-control 
data  base;  and  ADAMS,  one  of  the  a  series  tools  Fujitsu  called  "SIMPLE"  that 
operated  as  a  project-development  data  base  with  an  interface  to  other  tools, 
the  project  library,  and  management  data  bases. ^^  The  management  data  base 
kept  track  of  individual  personnel  and  projects,  primarily  in  the  form  of  man- 
hours  expended  per  phase  or  operation,  as  well  as  monitored  in-house  personnel 
costs  versus  those  charged  to  outside  contractors. 

ADAMS,  first  introduced  in  1982,  provided  support  from  detailed  design 
through  maintenance,  initially  of  programs  written  in  a  Japanese  version  of 
COBOL    or    the    macro-based    HYPER    COBOL.       Functional    menus    in    Japanese 
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eliminated  the  need  for  specialized  programming  commands.  ADAMS'  most 
important  functions  were  information  retrieval,  data-base  environment  definition, 
program  construction,  program  test,  utility  utilization,  and  historical  version 
control.  Information  retrieval  referred  to  the  storing  of  design  documentation 
in  the  form  of  tables  or  flow  charts  that  could  be  retrieved  for  modification  or 
reuse.  Fujitsu's  Japanese-language  COBOL  was  also  the  first  version  of  COBOL 
to  employ  Japanese  characters,    rather  than   the   representation   in   katakana.^^ 

From  1987,  all  new  applications  projects  in  the  factory  utilized  a  set  of 
tools,  including  YACII  and  YPS,  that  Fujitsu  referred  to  as  SDAS  (Systems 
Development  Architecture  and  Support  Facilities).  SDAS  continued  to  rely  on 
the  SDEM  methodology  but  integrated  many  of  the  tools  developed  after  1980. 
In  new-program  development  under  SDAS,  for  example,  system  engineers  used 
EPGII  (Executive  Planning  Guide  II)  and  C-NAPii  (Customer-Needs  Analysis 
Procedures  II)  to  define  the  customer  requirements.  These  tools  came  out  of 
the  SDEM  effort  to  standardize  and  simplify  the  specification  and  design 
process,  although  computer-aided  support  was  minimal.  EPGII  formalized  a  set 
of  planning  procedures  and  work  sheets  for  designing  corporate  information- 
management  systems,  mapping  out  a  customer's  needs  against  information- 
management  systems  already  existing  in  the  company.  C-NAPII  set  forth 
another  series  of  procedures  and  work  sheet  to  define  more  formally  the 
specifications   necessary  to  write  software.^' 

Noritoshi  Murakami,  a  manager  in  the  Software  Development  Planning 
Group,  presented  an  overview  of  automatic  programming  that  helped  placed 
Fujitsu's  efforts  in  tool  development  within  a  broader  spectrum  (Figure  7.10). 
In  this  interpretation,  "classical  automatic  programming"  consisted  of  compilers 
that  turned  computer  code  into  machine-readable  object  languages.  The 
"modern"  technology  --  represented  by  YPS  in  Fujitsu  as  well  as  similar  systems 
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in  Hitachi,  NEC,  Toshiba,  and  NTT  --  focused  on  automating  the  transformation 
step  from  program  design  specification  to  machine-readable  code.  These 
"program  design  specification  compilers"  read  structured  designs  or  diagrams 
(PAD  at  Hitachi,  SPD  at  NEC,  and  HCP  at  NTT)  and  generated  code  more  or 
less  automatically  (module  interfaces  might  have  to  be  written  manually),  usually 
in  COBOL,  FORTRAN,  or  C.  Two  additional  steps  were  to  move  automation 
further  back  in  the  development  life  cycle,  to  automate  part  or  all  of  the 
system  planning  and  design  phases.  Tools  such  as  Fujitsu's  Software  CAD 
attempted  this  through  transformation  rules  defined  by  the  user,  and  fell  into 
the  category  of  a  "partially  automatic  transformation  tool."  At  the  R&D  level 
in  Fujitsu  (and  in  many  other  firms)  were  tools  that  tried  to  automate  the 
transformation   process  through   Al   techniques. 

Automated  design-support  and  programming  tools  served  two  groups: 
experts  and  non-experts.  Fujitsu  developers,  on  the  one  hand,  maintained  that 
their  tools  would  'free  software  engineers  from  the  tedious  and  cumbersome  job 
of  writing  run-of-the-mill  computer  programs  and  turn  their  talent  to  more 
creative  work."  This  would  occur  because  programmers  no  longer  had  to 
compose  in  computer  languages  but  could  focus  on  business  problems  and  write 
programs  "more  finely  attuned  to  the  requirements  of  the  end-user."  On  the 
other  hand,  Fujitsu  designed  the  SDAS  tools  to  "enable  computer  users  to 
develop  their  own  application  software  without  the  help  of  expert 
programmers.  "^°  While  other  firms  provided  similar  capabilities,  Fujitsu  offered 
what  seemed  to  be  the  broadest  range  of  design-support  and  automated 
programming   tools   in   the  Japanese   software   industry. 

PARADIGM,  issued  around  1980  for  in-house  use  and  sold  since  1981, 
supported  module  design,  coding,  and  testing,  as  well  as  software  reuse  and 
program    maintenance    for    two    main    types    of    applications     software:        batch 
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processing  and  transactions  processing.  The  tool  relied  on  the  same  concept  as 
NEC's  STEPS  library  routines  and  Hitachi's  EAGLE  patterns.  Standard  patterns 
were  available  in  the  form  of  complete  functions  or  in  smaller  modules.  The 
PARADIGM  library  stored  both  specifications  (program  structure,  detailed  flow 
charts,  and  module  function  designs,  stored  in  the  form  of  flow  charts)  as  well 
as  executable  code.  Users  of  the  tool  would  first  access  the  specifications  from 
a  terminal  and  use  the  standard  patterns  to  write  up  a  design.  For  portions 
that  could  be  used  unchanged,  the  programmer  would  access  the  code  library. 
Changed  designs  would   be   recompiled   automatically. 

The  tool  stored  patterns  or  program  parts  in  a  library  according  to  a 
functional  name,  such  as  "input-out  check,"  that  made  it  possible  to  access 
parts  easily  and  reuse  designs  across  different  products.  In  addition,  users 
could  create  new  program  parts,  consisting  either  of  fully  coded  modules  or 
design  specifications  (program  outlines,  module  functions,  YAC  charts)  in 
COBOL,  using  a  structured  design  methodology,  and  then  register  them  in 
paradigm's  library  data  base,  causing  it  to  grow  with  each  new  piece  of 
software.  The  library  also  contained  utility  programs  for  use  on  multiple 
operating  systems,  referred  to  as  "black  box"  components.  To  assist  managers, 
paradigm  and  similar  tools  tracked  how  many  lines  of  source  code 
programmers  reused,  and  thus  supported  reuse  planning  in  the  design  phase 
(although  Fujitsu  did  not  include  reuse  objectives  in  project  schedules  and 
budgets  or  incorporate  them   in   design    reviews,    as   Toshiba  did.)^^ 

A  study  Fujitsu  published  in  1982  estimated  that,  in  80%  of  business- 
applications  programs  developed  with  PARADIGM,  personnel  generated  about  68% 
of  the  source  code  without  new  coding.  Since  about  two-thirds  of  business- 
applications  programs  seemed  redundant  and  suitable  for  reuse  technology, 
Fujitsu    managers    decided    to    invest    more    heavily    in    integrated    tool    and 
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methodology  sets  to  facilitate  reuse  both  of  source  code  and  design  patterns 
across  different  products,  mainly  in  COBOL,  where  the  logic  was  relatively 
simple. ^0 

ACS  PARADIGM  (Application  Control  Support  System)  was  a  refinement  of 
PARADIGM  for  developing  on-line  systems  through  modifiable  logic  tables.  The 
primary  objective  of  the  tool  was  to  simplify  the  design  of  files  and  the 
processing  structure  for  input  data.  The  major  improvements  were  to  offer 
users  more  functions  on  preset  screens  as  well  as  allow  more  flexibility  to 
describe  input/output  logic  for  new  applications  in  outline  form.  A  program 
generator  read  the  program  logic  and  then  produced  COBOL  code  from  tabular 
design  work  sheets  and  existing  input/output  routines.  In  addition,  ACS 
generated  code  from  preset  designs  (indexed  by  names)  for  specific  applications, 
with  blank  slots  to  be  filled  in  as  desired,  that  users  designated  for  insertion 
into  the  program.  ACS  stored  the  logic  tables  and  subroutines  in  a  parts  library 
to  facilitate   reuse  as  well   as  testing  and  maintenance.^' 

Programming  sections  in  the  Software  Factory  as  well  as  some  subsidiaries, 
software  houses,  and  customers  of  Fujitsu  hardware  used  a  similar  tool,  BAGLES 
(Banking  Application  Generator  Library  for  Extensive  Support),  to  produce  the 
longer,  more  complex  software  needed  to  control  automated  teller  machines  or 
to  move  funds  among  different  bank  locations  through  on-line  transfers."'^  The 
large  size,  frequency  of  demand,  and  similarities  in  functions  for  this  type  of 
software  led  Fujitsu  to  develop  a  dedicated  support  tool  for  this  industry  in 
1980.  Fujitsu  introduced  a  prototype  in  1981  and  then  versions  for  in-house  use 
and  commercial  leasing.  BAGLES  resembled  Hitachi's  EAGLE  and  NEC's  SEA-I, 
with  a  prescribed  design  format  in  Japanese,  a  design-document  data  base, 
automatic  COBOL  generation,  and  support  for  testing  and  project  management 
(Figure  7.11).     The  original  tool,  available  only  on  large  computers,  contained  2 
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million  lines  of  code  and  required  10  to  15  giga-bytes  of  mass  storage  to 
generate  programs  that  covered  from  500  to  1400  terminals  and  from  50,000  to 
150,000  transactions  per  hour. 

BAGLES  offered  simplified  logic-design  representations  in  tabular  form  and 
in  Japanese,  few  coding  errors,  a  simplified  program-control  structure,  reusable 
program  patterns  or  subroutines  for  common  banking  operations  and  functions, 
automatic  generation  of  documentation  in  Japanese,  and  support  for  testing  and 
management  control.  The  original  version,  however,  required  users  of  the  tool 
to  define  data  types  and  procedures,  specify  modules  and  the  logic  flow  of  the 
program,  and  determine  other  elements  in  almost  as  much  detail  as  writing 
COBOL  code.  This  meant  that  BAGLES  users  had  to  be  skilled  in  programming 
as   well   as   banking  applications. 

To  simplify  the  software-development  process  further,  Fujitsu  introduced 
BAGLES/CAD  in  1984,  through  which,  according  to  both  in-house  personnel  and 
customers,  users  with  little  knowledge  of  programming  could  develop  programs 
in  half  the  time  experts  using  just  COBOL  would  normally  require. 
BAGLES/CAD  also  ran  on  personal  computers  or  work  stations  attached  to 
larger  computers  and  data  bases,  and  provided  graphics  capabilities  as  well  as 
"windows"  that  allowed  users  to  expand  or  contract  the  graphical 
representations  of  a  program  in  order  to  view  the  whole  system  (or  a  large  part 
of  It)  as  well  as  focus  on  the  structure  of  individual  modules.  The  improved 
format,  including  revised  decision  tables,  helped  users  define  banking  operations 
and  integrate  packaged  subsystems  and  reusable  patterns  with  new  designs.  As 
with  the  original  BAGLES,  all  the  graphical  design  representations  were 
executable  as   COBOL  code. 

A  similar  tool,  CASET  (Computer-Aided  Software  Engineering  Tool), 
supported    development    of    relatively    simple    business     applications    programs 
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written  in  COBOL,  consisting  largely  of  relational  data-base  subsystems  and 
information  lists,  such  as  for  inventory  or  sales  control.  After  the  user  defined 
specifications  in  Japanese,  the  tool  produced  a  program  design  and  automatically 
coded  the  designs,  while  a  debugging  support  subsystem  and  document  generator 
facilitated  testing  and  maintenance."^ 

Advanced  Design-Support  Tools 

PARADIGM,  ACS-APG,  CASET,  and  BAGLES  were  useful  for  well-defined 
applications  described  in  decision  tables  or  menu-driven  design  sheets  and 
libraries  of  patterns  or  subroutines.  To  automate  development  of  software  for 
new  applications  required  tools  extending  beyond  pre-existing  designs,  library 
routines,  menus,  tables,  or  development  methods.  Software  CAD,  though  still 
experimental,  was  the  most  advanced  tool  of  this  type  used  in  Fujitsu  as  of 
1988-1988.^ 

Engineers  described  Software  CAD  as  "a  general  tool  for  the  drawing, 
verification,  and  transformation  activities  of  software  development.  .  .  independent 
of  any  particular  methods  or  development  phases.  .  .  .  Software  CAD  is  a  general 
tool  that  developers  can  customize  to  fit  particular  methods  for  their  own 
circumstances."  Fujitsu  completed  a  version  and  introduced  it  into  Kamata  in 
1987,  initially  for  writing  segments  of  business  applications  programs.  Projects 
were  gradually  extending  its  use  to  other  areas,  such  as  to  develop  operating 
systems,  switching  systems,  communication  software,  and  "firm-ware"  (micro- 
code embedded   in    semiconductor  chips). 

The  1987  version  of  Software  CAD  used  generalize-purpose  notations 
combining  text,  tables,  and  diagrams,  as  well  as  an  editor  and  compilers  that 
transformed  standardized  notations  into  modifiable  design  documents  and  then 
different  types  of  code.     The  notation  system  contained  six  types  of  objects  for 
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describing  program  structures:  forms  (graphic  models  of  the  program),  tables, 
nodes  (graphic  symbols  specifying  particular  attributes  of  the  program),  edges 
(symbols  representing  connections  between  nodes),  inclusions  (symbols 
representing  relationships  between  nodes  and  edges),  and  text  fields  (inputs  of 
data  into  any  of  the  objects).  The  NS  (Notation  Specification)  Compiler  took 
specifications  written  by  program  developers  in  the  specified  format  and 
produced  machine-readable  notations.  These  became  inputs  to  the  Software 
CAD  editor  for  modification,  which  the  tool  deposited  in  the  Software  CAD 
Document  Database  when  finished. 

The  Software  CAD  Editor  allowed  the  user  to  access  the  Document 
Database  and  modify  any  of  the  objects,  relying  on  templates  as  well  as  a 
"mouse"    interface    and    a    "multi-window    environment."  The    Software    CAD 

Transformer  relied  on  rules  the  user  specified  to  transform  the  documents 
stored  in  the  database  into  either  executable  code  or  textual  documentation 
(Figure  7.12).  The  notation  system,  according  to  Fujitsu,  was  relatively  easy  to 
learn,  requiring  a  few  hours  for  an  experienced  programmer  and  a  few  days  for 
a  new  employee.  Describing  the  transformation  rules  was  not  simple,  although 
Fujitsu  claimed  that  programs  developed  with  Software  CAD  still  came  out 
faster  than  comparable  systems  done  manually. °^ 

Ongoing  R&D  in  Fujitsu  attempted  to  integrate  artificial  intelligence 
techniques  with  Software  CAD  and  apply  Al  in  other  support  tools.  Fujitsu's 
approach  was  to  use  Al  techniques  to  process  design  documents  using  a 
"knowledge  data  base"  for  specific  applications,  a  model  of  the  desired  design, 
and  a  "knowledge  transformation"  algorithm.  For  example,  based  on  inferences 
made  in  processing  the  documentation,  a  tool  would  produce  documents  for  a 
subsequent  phase  --  planning  inputs  would  produce  a  detailed  system  design, 
which  would  be  processed  into  a  program  design,   which  would  be  transformed 
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(compiled)  into  source  code.  Fujitsu  engineers  were  especially  interested  in 
applications  to  requirement  specification  and  lexical  (design-language)  editors, 
since  Al  appeared  useful  to  help  designers  understand  constraints  in  hardware, 
the  operating  system,  the  computer  language,  or  specific  applications,  and  to 
verify  designs.  One  Lisp-based  expert  system  was  available  in  prototype  form  to 
help  inexperienced  personnel  consult  with  customers  and  produce  customized 
systems  for  a  variety  of  applications. °"  Fujitsu  also  applied  inference-search 
methods  to  identifying  software  components  for  reuse,  and  was  studying  testing 
support  and  maintenance  applications,    such   as   problem  diagnosis. 

In  the  telecommunications  area,  a  tool  employing  Al  became  available  for 
switching-systems  development  in  1984,  the  SDL  (Specification  and  Description 
Language)  Support  System.  Fujitsu  Laboratories  began  working  on  this  in  the 
late  1970s,  writing  in  UtiLisp.  SDL  resembled  NEC's  SDMS  and  contained 
graphic  symbols  to  represent  different  states,  tasks,  or  signal  input  and  output; 
graphics  as  well  as  text  editors;  a  document  data  base;  automatic  document 
compilation  and  inspection  subsystems;  a  "knowledge  data  base"  of  different 
functions  or  tasks  performed  in  a  switching  system;  and  subsystems  to  translate 
the  graphically  represuented  requirements  into  state-transition  diagrams  and  then 
these  into  executable  code.  This  was  an  "intelligent  system"  in  the  sense  that 
it  withdrew  information  from  the  graphical  designs  and  deposited  this 
information  in  a  data  base  in  the  form  of  general  and  detailed  state-transition 
diagram  elements.  Subsystems  then  used  inference  rules  to  produce  I/O 
transformations  automatically  and  generate  computer  code."' 

Architectural  Standardization  and   Package  Utilization 

SIA  or  Systems   Integration  Architecture,   which   Fujitsu  announced  in  1 
along    with    the    SDAS    tool    set,     aimed    at    creating    a    standard    interface 
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programming  in  COBOL,  FORTRAN,  C,  LISP,  or  PROLOG  and  using  the  different 
SDAS  tools  and  applications  packages  on  Fujitsu  mainframes,  office  computers, 
and  work  stations  (Figure  7.8).  The  interface  was  not  complete  in  1989  but 
Fujitsu  expected  it  to  be  available  for  all  machines  within  a  few  years. 
Management  also  viewed  the  SIA  architecture  as  complementary  to  its 
production  strategy,  since  SIA  was  expected  to  ma-ke  it  easier  to  break  up  large 
programs  into  distinct  units  that  programmers  could  develop  on  different  work 
stations  and  then  combine  later.  °° 

Increasing  package  use,  especially  across  different  machines,  was  a  key 
objective  at  Fujitsu,  even  in  custom  programming."^  The  reasons  were  clear 
and  well-established  at  firms  such  as  Toshiba:  Reusing  software  in  custom 
development  represented  a  reuse  of  know-how  that  usually  reduced  the  amount 
of  new  effort  required  for  product  development.  The  exception  was  when 
developers  had  to  change  too  much  of  the  designs  or  code  they  reused.  A 
major  challenge  was  thus  to  produce  packages  that  could  fit  as  is  into  larger 
systems  ,  or  build  them  so  that  it  was  relatively  easy  to  tailor  the  software  to 
fit  individual   user  needs  or  changes  in  technology.  Some  technical  avenues 

Fujitsu  pursued  were  to  promote  reuse  of  designs  as  well  as  program  more  in  C 
and  use  object-oriented  design.  Organizationally,  management  also  kept  package 
design,  and  some  coding,  in  the  specialized  system-engineering  departments,  to 
take  advantage  of  specific  application-related  or  functional   expertise. 

The  Fujitsu  group  relied  on  two  package  registration  systems  to  promote 
use  of  existing  software.  The  largest  catalogued  original  Fujitsu  packages, 
totalling  about  1000  in  1986  and  increasing  40%  to  50%  per  year.  Another 
library  registered  software  users  or  computer  dealers  developed;  in  1986  this 
totalled  about  300.''  Figure  7.9  summarizes  data  on  how  well  these  packages 
covered  user  needs.     Manufacturing  systems  extended  over  the  broadest  range, 
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with  larger  ones  requiring  total  customization  and  some  systems  containing  more 
than  40%  existing  code  from  packages.  Fujitsu  found  that  it  could  more  often 
meet  the  needs  of  small-system  users  by  packages,  such  as  in  the  case  of 
hospitals  and  newspaper  companies.  Overall,  data  suggested  that  SDAS-based 
applications  packages,  covering  financial,  manufacturing,  distribution, 
government,  newspaper,  and  medical  applications,  accounted  for  40%  of 
applications   systems   Fujitsu   delivered   in   1988.'^ 

Performance  Improvement 

Although  some  of  the  data  Fujitsu  released  about  projects  built  in  the 
Software  Factory  was  difficult  to  interpret  and  compare  to  other  firms,  the 
information  available  indicated  improvements,  especially  in  productivity, 
comparable  to  Hitachi,  Toshiba,  and  NEC,  as  well  as  other  firms  using  similar 
methods  and  tools.  For  example,  in  a  1981  article,  a  team  that  worked  on 
revising  the  SDEM  standards  claimed  their  introduction  brought  roughly  a  20% 
gain  in  productivity  (delivered  lines  of  code  per  month,  normalized  to  170-hour 
months)  over  projects  not  using  the  methodology.  These  gains  came  mainly 
from  the  "absence  of  rework,"  achieved  through  better  work  scheduling,  early 
discovery  of  problems,  standardization  of  work  and  documentation,  and  use  of 
formal  planning  and  reviews  to  reduce  differences  between  user  requirements 
and  finished  programs.'^  With  SDEM  in  place  and  tool  and  methodology 
development  continuing,  Fujitsu  managers  later  asserted  that  productivity 
doubled  from  1980  to  1984,  and  rose  during  1984-1988  between  5%  and  15% 
annually,   due  to  a  combination  of  factors: 

(1)  Equipment   --    investment    in    more   time-sharing    terminals,    work    stations, 
and  other  computer-center  facilities   in   the  Software  Factory. 

(2)  Specialization  --   accumulation  of  programming  and  development  know-how 
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by  system  engineers,  groups  in  the  Software  Factory  and  software  houses. 

(3)  Standardization  --  introduction  and  enforcement  of  standards  for  program 
documentation  as  well  as  for  the  development  process  and  linked  support 
tools. 

(4)  Tools  --  greater  application  of  computer-aided  tools  for  supporting  testing 
and  design,    including   reuse  support. 

(5)  Reviews  --  formalization  of  review  procedures  and  checklists,  as  well  as 
development  of  automated  tools   to  assist   in   code   reviews. 

(6)  Project  Management  --  introduction  of  productivity  standards  and  revision 
of  the  quality-control  process,  including  use  of  quality  objectives  and  data 
collection.  '^ 

Among  these  elements,  Fujitsu  data  suggested  that  most  productivity  gains 
after  1985  came  from  computer-aided  tools  such  as  PARADIGM  and  reuse 
technology,  including  the  integration  of  packages  into  customized  systems.  One 
reason  was  the  reduction  in  man-hours  required  in  new  program  development 
through  recycling  of  designs,  code,  and  documentation,  and  minimization  of 
debugging  for  reused  components.  Second,  Fujitsu  claimed  that  PARADIGM  and 
similar  tools  "enabled  even  inexperienced  programmers  to  write  high-quality 
programs"  and  "eliminated  misunderstandings  due  to  individual  differences"  by 
making  design  documents  and  code  easier  to  read  and  maintain,  due  to  the 
highly  structured  methodology.'^  The  result  was  that  managers  could  deploy 
their  skilled  engineers  more  effectively. 

paradigm's  exact  impact  on  productivity  varied  with  the  application,  the 
phase  of  development,  and  the  number  of  times  that  application  appeared.  Data 
from  1982  showed  that  use  of  PARADIGM  tended  to  cut  in  half  the  time 
required  for  program  design  as  well  as  basic  programming  activities  (coding, 
compiling,    and    debugging).       Time    spent    in    other   aspects    of    integrated    and 
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system  test,  including  test  preparations,  remained  similar.  Overall,  Fujitsu 
projects  using  PARADIGM  experienced  a  doubling  of  productivity,  compared  to 
comparable  projects  done  manually,  with  more  time  or  man-hours  shifted  from 
design  and  coding  to  testing.  Projects  also  saved  on  man-power  by  generating 
up  to  80%  of  design   documents   from  standard   YAC  patterns.    " 

Fujitsu  reported  similar  quality  improvements  with  PARADIGM.  From  an 
average  rate  of  approximately  10  errors  per  1000  lines  of  code  detected  in 
module  tests,  programs  written  with  the  tool  averaged  2  or  3  per  1000  lines  and 
between  0  and  1  for  particularly  repetitive  applications.  Most  of  the  erro--' 
introduced,  furthermore,  were  not  in  the  PARADIGM  components  but  in  newly 
written   additions.'' 

Using  ACS  to  develop  a  small-scale  conversational-mode  data  entry  system 
of  approximately  10,000  lines  of  COBOL  source  code,  Fujitsu  reported  a  short- 
term  decline  in  productivity  in  order  to  write  reusable  code  but  significant 
improvement  over  expected  standard  times,  minus  the  defined  paradigms,  as  well 
as  a  larger  gain  when  producing  a  similar  program  in  the  future  (Table  7.8).  In 
one  project,  users  of  the  ACS  tool  averaged  1219  lines  of  code  per  man-month 
versus  587  lines  per  man-month  for  similar  COBOL  programs  done  without  the 
tool.  The  numbers  for  the  ACS  project  excluded  12  man-months  required  to 
write  1817  lines  of  code  contained  modules  that  became  part  of  the  reusable 
ACS  PARADIGM  library.  If  added,  this  work  dropped  the  net-productivity  rate 
for  the  ACS  project  to  495  --  below  the  factory  standard.  In  a  larger  but 
similar  project,  which  consisted  of  converting  and  extending  a  program  using 
some  of  the  ACS  PARADIGM  patterns  and  modules,  productivity  was  1864  lines 
per  man-month,  and  the  project  was  able  to  reuse,  or  automatically  generate 
from  designs,  42%  of  the  source  lines.  This  limited  data  suggested  that  ACS 
PARADIGM  could  reduce  time  required  in  all  phases  of  development,   if  designs 
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were  reusable.  '° 

In  using  BAGLES  (and  BAGLES/CAD)  for  banking  programs  of  2  to  3 
million  lines  of  COBOL  source  code,  Fujitsu's  experience  as  of  1987  indicated 
that  the  tool  brought  a  25%  reduction  in  man  hours  compared  to  program 
development  in  COBOL.  BAGLES  achieved  this  primarily  by  cutting  time 
required  for  programming  (program  design,  coding,  and  debugging)  through  the 
use  of  a  highly  structured  design  format.  There  was,  however,  a  slight  increase 
in  time  allocated  to  system  design,  compared  to  programs  developed  in  COBOL. 
BAGLES/CAD,  on  the  other  hand,  drastically  reduced  design  time  through  the 
use  of  graphics  and  windows  and  the  reuse  of  design  patterns,  and,  compared  to 
COBOL,  cut  total  development  time  for  similar  programs  to  less  than  half  (Table 
7. 9). 79 

The  combination  of  SDAS  tools  and  packages  again  doubled  productivity,  at 
least  in  one  major  case  when,  for  a  banking  customer,  Fujitsu  replaced  an  old 
software  system  consisting  of  3.6  million  lines  of  code.  Existing  packages  had 
covered  30%  of  the  old  system  and  man-months  required  for  the  complete 
system  was  8000.  Thus,  the  original  system  had  a  gross  productivity  rate  of 
450  lines  of  code  per  man-month.  The  more  sophisticated  replacement  was  more 
than  twice  as  large  --  8.3  million  lines  of  code.  But  Fujitsu  was  able  to  obtain 
79%  of  the  code  from  SDAS  packages  for  securities  processing,  customer 
control,  cost  accounting,  international  transactions,  foreign  exchange  dealings, 
regional  information  control,  and  a  general  data  base,  as  well  as  for  the  outside 
network,  store  operations,  accounting,  and  general  operations.  For  the  other 
21%  that  employees  had  to  develop  anew,  they  used  YPS  and  BAGLES  to 
generate  code.  The  resulting  gross  productivity  was  902  lines  of  code  per  man- 
month   (Table  7.10  and   Figure  l.U).^^ 

The    length    of   the    second    system    suggests    that    reusing    so   much    code, 
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designs,  or  packaged  subsystems  might  result  in  high  nominal  productivity  but 
lengthy  programs  --  perhaps  longer  than  necessary.  It  was  clear  that  reuse 
aided  nominal  productivity  (see  Appendix  B),  although  writing  unnecessarily  long 
programs  exaggerated  productivity.  While  this  was  possible,  the  new  Fujitsu 
system  in  this  example  appeared  to  offer  a  much  wider  range  of  functions. 
While  it  was  not  possible  for  this  author  to  examine  and  interpret  the  code, 
Fujitsu  also  claimed  that  reuse  did  not  necessarily  add  to  a  program's  length. 
Another  article  even  asserted  that  reusing  efficient  modules,  aided  by  design- 
support  tools,  could  reduce  length.  For  example,  programs  built  with  BAGLES 
tended  to  be  shorter  than  software  performing  similar  functions  written  without 
the  tool  --  as  much  as  l/14th  the  size.  Fujitsu  maintained  this  was  because,  in 
developing  BAGLES,  engineers  identified  a  large  number  of  repetitious  functions 
that  could  be  handled  through  subroutines,  and  later  users  of  the  tool  could 
cite  these  repeatedly  in  the  program  without  rewriting  the  code.°' 

On  the  other  hand,  along  with  Toshiba  and  Hitachi,  Fujitsu  encountered 
limits  to  the  benefits  of  reusing  designs  and  code,  depending  on  how  much  of 
the  component  or  subsystem  programmers  had  to  modify.  In  applications 
development,  Fujitsu  projects  indicated  a  "break-even"  point  of  about  60%  for  a 
given  piece  of  software:  If  employees  had  to  rewrite  more  than  60%,  then  the 
impact  on  overall  productivity  of  reusing  the  designs  or  code  was  slightly 
negative. °*^  More  detailed  data  from  Numazu  was  similar,  showing  a  clear 
improvement  in  productivity  as  long  as  personnel  reused  70%  to  80%  of  a 
particular  module  or  program  part  without  significant  changes:  In  a  sample  of 
47  projects,  median  productivity,  including  man-power  devoted  to  maintenance, 
was  approximately  60%  higher  with  20%  new  code  and  an  80%  reuse  rate.  In 
projects  where  there  were  attempts  to  reuse  code  but  less  than  70%  was 
reusable  without  significant  changes,    the  impact  on   productivity  tended  to  be 
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negative. ^*^ 

Software  CAD  appeared  to  improve  productivity  without  necessarily 
recycling  existing  code  or  designs,  but  through  partially  automating  the 
transformation  of  design  specifications  into  code.  While  Fujitsu  used  the 
present  tool  only  for  a  few  tasks,  results  in  limited  trials  were  impressive. 
Software  CAD  cut  the  time  needed  to  develop  a  tool  to  convert  a  set  of  job- 
control  diagrams  to  job-control  language  from  a  normal  6  months  to  1  month, 
and  total  manpower  from  a  standard  9.3  man-months  to  0.5  man-months. 
Programmers  using  Software  CAD  were  able  to  transform  a  database  logic 
structure  diagram  into  programming  language  (ADL)  in  one-sixth  the  time  (8.4 
man-months  to  0.5  man-months)  usually  required  for  similar  jobs.  Other  efforts 
showed  comparable  improvements,  usually  cutting  development  time  one-fourth 
or  one-third  from  expected  levels,  with  even  larger  gross  productivity  gains, 
compared  to  conventional  design  and  programming   (Table  7.11).°^ 


SUMMARY  AND  EVALUATION 

Fujitsu's  approach  to  software  development,  as  summarized  in  Table  7.12, 
closely  resembled  those  at  Hitachi,  NEC,  and  Toshiba,  with  some  minor 
exceptions  and  different  emphases.  Most  notable  at  Fujitsu  were  its  early  focus 
on  and  intermingling  of  process  and  quality  control  in  basic  software; 
establishment  of  a  centralized  laboratory  in  1970  and  then  a  factory  for 
applications  programming;  extensive  investment  in  an  assortment  of  design- 
support  tools  for  custom  programming,  some  dedicated  to  specific  industry 
applications  and  for  non-specialized  users;  and  investment  in  building  software 
packages  not  so  much  to  sell  but  more  to  integrate  into  customized  applications 
products.       Fujitsu    also  created   the   largest   network   in   Japan   of   subsidiaries, 
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much  as  Hitachi  and  NEC  did,  but  on  a  larger  scale.  Furthermore,  again  on  a 
larger  scale  than  Hitachi  or  NEC,  Fujitsu  used  software  houses  to  provide  most 
of  the  manpower  for  its  applications  software  factory,  eliminating  the  need  to 
find  and  hire  large  numbers  of  permanent  programming   staff. 

Another  characteristic  of  Fujitsu  was  a  healthy  combination  of  continuity 
and  adaptability,  in  strategy,  technology,  and  organization .  Hardware  engineers 
stayed  too  long  with  telephone  relay  circuits  but  then  switched  to  transistors 
when  these  became  the  obvious  technology  to  use.  Management  pursued  a 
foreign  source  of  technology,  decided  to  develop  computers  independently  when 
it  could  not  find  a  good  partner,  and  sought  a  partner  again  after  the  death  of 
its  key  designer.  In  software,  like  SDC,  Fujitsu  experienced  some  difficulty 
separating  system  design  from  product  construction  in  the  software  factory. 
Rather  than  abandoning  the  goals  of  centralization  and  rationalization,  however, 
management  adopted  different  processes  for  different  projects,  bringing  more 
design  operations  into  the  factory  where  appropriate,  and  continuing  to  invest 
heavily  in  standardized  tools,  methods,  reuse  libraries,  and  training  of  in-house 
personnel  and  employees  from  subsidiaries,    subcontractors,    and  customers. 

What  the  concept  of  a  software  factory  meant  in  Fujitsu's  context  thus 
varied  by  the  type  of  product,  as  at  other  Japanese  firms,  as  well  as  over  time. 
Both  Numazu  and  Kamata  pursued  centralization  of  personnel,  standardization  of 
practices  and  tools,  improvement  in  product  reliability  and  productivity,  and 
formal  management  controls  and  objectives  such  as  reusability.  But  only 
Kamata  pursued  a  formal  division  of  labor  separating  design  from  product 
construction,    and  then  gradually   relaxed  this   policy. 

In  sum,  though  somewhat  late  in  entering  the  computer  industry  and  the 
business  of  establishing  software  factories,  Fujitsu  clearly  allocated  the 
resources    and    management    attention     it    needed    to    develop    a    system    for 
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producing  programs  to  support  its  computer  products.  The  outcome  was 
Fujitsu's  position,  since  the  late  1960s,  as  Japan's  largest  producer  of  computers 
and  related  products  and  services,  as  well  as  its  continual  demonstration  of 
broad  competence  across  a   range  of  hardware  and   software  markets. 
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Figure  7.1:      FUJITSU  OPERATING  GROUPS   n986) 


Group 

Computer  Systems 

Printed-Circuit  Board   Products 

Information   Equipment 

Transmission   Systems 
Switching   Systems 
Telecommunications   Systems 
Semiconductors 
Electronic  Devices 
Electronic  Devices   Exports 
Systems   Engineering 

Field  Service  Engineering 
Systems   Sales 
Office  Automation   Sales 
NTT  Sales 


Comments 

(Mainframe  and  Minicomputer  Hardware 
and  Software,    Factory  Automation) 

(Office  Equipment  and  Personal 
Computers,  Work  Stations,  Terminals, 
Software) 

(Disk  Drives,  Printers,  Facsimile 
Machines,   Other  Peripherals) 


(Large-Scale     Custom     Applications, 
Applications    Packages) 

(Hardware  Maintenance) 


Source:    Nikkei  Computer.    13  October  1986,    pp.    70,    79. 
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Figure  7.2:      FUJITSU   PRODUCTIVITY   IMPROVEMENT  STRATFGIFS 


Development  Technology  Specialization 


Common    Development 

Modularization 

High-Level    Languages 

Reuse 

Review   Procedures 

Structured   Design 

Structured   Programming 


Organizational 
Structure 

Subsidiaries 

Software 
Packages 


Mechanization/Automation 

Software  Tools   and  other 
Computer-Aided   Systems 
for   Planning,    Development, 
Testing,    Maintenance 


Project  Management 


Support  and  Control  Technology 

Standardization 


Development   Planning   and   Phase 
Completion    Reporting   System 

Management  Objectives 


Quality  Control   Activities 
(High-Reliability   Program) 

Training 


Source:  "Software  Kaihatsu,"   p.    4. 
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Figure  7.4:    SYSTEMS  ENGINEERING  GROUP  ORGANIZATION 


COMMON  TECHNOLOGY  DIVISIONS 

—  SE  Technical   Support  Center 

--   Software  Factory  Department 

--    Information   Support  Center  Department 

--   Technology  Transfer  Department 
--   System  Engineering  Support  Services   Department 
--   Office  Computer  Systems   Support  Service   Department 
--   SIGMA   Project  Systems   Promotion   Office 

Application   Software   Planning   Division 

--   Application   Software   Planning   Department 
--   Software   Distribution    Department 

—  Fujitsu    Research    Institute  for  Advanced   Information   Systems  and 
Economics 


INDUSTRY-RELATED  DEPARTMENTS 

—  Finance 

—  Insurance/Securities 

—  Manufacturing/Distribution 

—  Scientific/Technical 
---  NTT 

—  Government/Mass -Communication 


FUNCTIONAL  DEPARTMENTS 

—  Management   Information   Systems   Division 

—  VAN    (Value-Added   Network)    Systems   Engineering   Division 

—  Information    Network  Systems   Engineering   Division 

—  Personal   Computer  Systems   Engineering   Division 

—  NCC   (New  Common   Carriers)   Systems   Engineering   Division 


SYSTEM  ENGINEERING  SUBSIDIARIES 

—  Industry  and    Functional 

—  Regional 


Source:  Murakami     Correspondence,     received    12/26/88.        Original    version     in 
Nikkei  Computer.    13  October  1986,    p.    79. 
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Figure  7.5:      SYSTEM  ENGINEERING  GROUP  TRAINING   AND  CAREFR   PATHS 

Assignment  to  Factory  Divisions 


Yearl 


Education 
Department 

New  Entrant  »» 
Education 


Training   in   >>>> 
Divisions 


Project  Work  »» 
Introduction 


Training 
Content 

Joint  Sessions: 

Languages 

OS 

System  Design 

SDEM  Methods 

Factory  Work 
Standards 

On-the-job 
Instruction 

Project  Standards: 

Process 

Tool   Use 

Documentation 

Coding 

Time 

3  Months 

1-2  Months 

7-8  Months 

Year  2 
to       4 

Project  Work 

Modu 

le  Design   »>> 

Coding  »» 

Programming  >>>> 

Module 
Test 

Test 
ficati 

Speci- 
ons 

Structural 
Design 

Training 
Content 

Junior:        Writing 
System 

an 
De 

d  Speaking,   In 
!sign,   Product- 

formation  and  Communications, 
Specific  Skills  and  Information 

Regular:     Project    Management,     Contracts     and     Law,     Network 
Structure  Design   and    Requirements   Analysis 

Titles  Junior  System   Engineer      (1.5  to  3  years   experience) 

System  Engineer  (3  to  13  years  for  high-school  graduates; 

3  to     9  years   for  college  graduates) 

Year  5               System  Design  Work 
Plus  


Year  5 
Plus 


Training 
Content 

Titles 


Logic  Design  >>»       Initial   Design 
Integrated  System 

Test  Test 


Project  Management  and  Support  Work 

Scheduling,    Quality,    Budget  Control   and   Risk  Management 
Development   Process  and   Project-Management  Methods 
Tool    Planning  and   Development 

Continues   Regular  Curriculum  for  System  Engineers 


Senior  System  Engineer   (from  9  to   13  years  experience) 


Source: 


Narafu   correspondence;    Fujitsu    Ltd.,    "Kyoiku  jigyo  no  gaiyo. 
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Figure  7.8:  Systems  Develo 
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Figure  7.9:   Package  Coverage  Ratio 
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Figure  7.11:      BAGLES   PROCESS-FLOW  OUTLINE 
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Figure    7.12:      Software   CAD 
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Table  7.1:      FUJITSU   SOFTWARE  SUBSIDIARIES  AND  EMPLOYEES   f1987) 


Software  Area 

System  Engineering 

Basic  Software 

Communications 

Microprocessors   and 
Personal   Computers 

TOTAL 


Companies 

EmDloyees 

37 

7,800 

9 

3,000 

7 

2,400 

3 

900 

58 


14,100 


Source:  Murakami   Correspondence  to  Cusumano,    12/26/88. 
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Table  7.2:    FUJITSU   BASIC-SOFTWARE  PACKAGES.    1962-19ft4 

1960  ALGOL  compiler 

1961  ASSEMBLER  compiler 
FORTRAN   compiler 

1963  Data  communications   software 

1965  FORTRAN    IV  compiler 

MOP    (control   program  for  the   FACOM  230-20/30  mainframes) 
MONITOR   II    (proto-operating   system  for  the  FACOM  230-50) 

1966  KEMPF    (econometrics   modeling   and   analysis   system) 

1968  MONITOR  V   (large-scale  mainframe  operating   system) 
STAT    (statistical   package) 

1969  BOS    (medium-size  mainframe  batch  operating   system) 

ROS    (medium-size  mainframe   real-time  processing  operating   system) 

PL/I   compiler 

EPOCS    (medium-size  mainframe  data  control   program) 

ADSL   (continuous   simulation   system) 

1970  RAPID   (data   base  system) 

1971  MONITOR  V  TSS    (time-sharing  function   added  to  MONITOR  V) 
BOS    II    (successor  to   BOS   and    ROS  operating   systems) 

OS    II    (operating   system  for   FACOM  230-45/S   and  /55  mainframes 
ASTRA   (structural   analysis   program) 

1972  UMOS    (mini-computer  operating   system) 
TIMS    (time  series  analysis   program) 

1973  MDS    (management  decision-making   support  tool) 
MPS    (mathematical   planning  tool) 

1974  BOS/VS    and    OS    ll/VS    (medium-size    operating    systems    with    virtual 
memory  control   function) 

MONITOR  VI/VII    (large-scale  mainframe  operating   system) 

1975  OS   IV/F4   (operating   system  for  largest  M-series  mainframe) 
FEM   (finite  element  analysis   program) 

1977  AIM   (on-line  data  base  system) 
FNA    (Fujitsu    Network  Architecture) 

OS    IV/X8   (medium-size  operating   system   for   FACOM  M   series) 
OS   IV/F2   (small-size  operating   system  for   FACOM  M  series) 
PDL/PDA    (performance  measurement  and   analysis   tool) 

1978  OS/UAS   (mini-computer  operating   system) 
FAIRS-I    (information    retrieval    system) 

KING    (Japanese-language  line  printer  support  program) 

77  Fujitsu 


1979  JEF    (Japanese-processing   Extended    Feature) 
INTERACT    (end-user  support  system) 
FAIRS-II    (management  information   search   system) 
FDMS    (document  control   system) 

GEM   (library  control   program) 

SSOPTRAN    (FORTRAN   source  program  optimizer) 

1980  FORTRAN??  compiler 

AOF    (computer  center  operations   support  tool) 
ARIS    (resident  information   system) 
HOPE   (hospital   administration   system) 

1981  OS    IV/F2   ESP    (small-scale  operating   system  for   FACOM  M-series) 
ICAD   (computer  design   support  system) 

HYPER   COBOL   (high-productivity  version  of  COBOL) 
DOCK/FORTRAN??    (FORTRAN   debugger  for  system  displays) 
ANALYST   (statistical   data   processing  package) 
PLANNER    (planning   and   control    information   system) 
AXEL   (conversational    language  data   analysis   system) 

1982  OS    IV/F4  MSP    (large-scale  operating   system  for   FACOM  M-series) 
AIM/RDB    (relational   data   base  system) 

DRESSY/P    (simplified  graphics   system) 

ADAMS    (Application   Development  and   Management  System) 

1983  FOS   (Fujitsu   Office  System  Concept) 

OS    IV/X8   FSP   (medium-size  operating   system  for  FACOM  M-series) 

UNICUS    (minicomputer  operating   system) 

JEF   II    (Japanese-processing   Extended   Feature   II) 

MACCS/REACCS    (information   analysis   and   search    system) 

ODM   (documents   processing   system) 

ELF    (electronic  file  system) 

1984  OS    IV/ESP    III    (small-scale  operating   system  for   FACOM  M-series) 
IMPRESS    (image  information   system) 

IPS    (small-scale  printing  control   system) 
UPLINK    Ill/PS    (personal   computer   network   system) 
FCAD-11    (personal   computer  CAD   system) 
ATLAS    (automatic   language  translation   system) 


Source:  "FACOM  no  ayumi"  (FACOM  development),  FACOM  janaru.  Vol.  11,  No. 
1  (1985),  pp.  20-47;  and  Fujitsu  Kabushiki  Kaisha,  "FACOM  seine 
ichiran"  (Overview  of  FACOM  performance)  in  Ikeda  kinen  robun  shu 
(Anthology  of  articles  in  memory  of  Ikeda),    Tokyo,    1978,   pp.    254-267. 
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Table  7.3:    CHRONOLOGY  OF  BASIC  SOFTWARE   PROCESS  DEVEI  OPMENT 

1966  Programming    (Software   Engineering)    Department  established. 

1968         Program  Testing  Section  established. 

1970  "Strengthen  Inspection"  effort  begun  (1970-1973),  extending  testing  from 
debugging  to  evaluating  software  from  the  user's  perspective,  such  as 
comparing   performance  to  specifications   stated   in   manuals. 

1971  Software  Product  Registration  System  .  established,  requiring  new 
software  to  undergo  inspection  and  receive  product  numbers  before 
being  released.  Product  Handling  Regulations  formalized  procedures  for 
software  products,  manuals,  and  documentation.  Required  all  product 
components  to  be  brought  in  simultaneously,  not  one-by-one,  to  the 
inspection   department  for  testing   and  evaluation. 

1972  Planning   Section   established. 

1973  Preliminary  version  of  Development  Planning  and   Report  System. 

"Application  of  QC  Techniques"  effort  begun  (1973-1978),  aimed  at 
forecasting  and  then   eliminating  bugs. 

MTS    (Multi-Terminal   Simulator)    tool   developed   for  testing. 

1974  Software  Division   established. 

"Product  and  Process  Standardization"  effort  for  begun.  Involved 
estimating  what  the  phases  would  be  for  the  life  cycle  of  individual 
software  products,  and  then  determining  what  to  design  in  a  given 
period  of  time,    as  well   as   what   programming   techniques   to   use. 

Bar  charts   instituted  for  project  control,    replacing   PERT  charts. 

Inspection  procedures  and  forms  standardized   (Main   Factor  Analysis). 

HTS   (Hardware  Trouble  Simulator)   tool  developed  for  testing. 

1975  Phase  divisions  formalized  and  SWN  (Software  Normen)  Standards  effort 
launched. 

BSMS   (Basic  Software   Project  Management  Support  System)   started. 

Procedures  for  bug  analysis  and  data  gathering  formalized."  QC  Data 
Accumulation"   effort  formally  begun. 

Estimates  Handbook  drawn  up,  with  actual  data  on  past  projects  to  aid 
managers   in   estimating  project   requirements. 

1976  Software  Administration    Department  established. 

BSMS   data   base  started   for  project  control   and   estimation. 
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Current  Development  Planning  and  Report  System  instituted,  software 
product  delivery  procedures  formalized,  and  BSMS  required  for  in- 
house   use. 

1977  "Inspection  of  Quality  and   Evaluation   Indicators"    (1977-1978)   begun. 

1978  Structured  design   and  programming  emphasized. 

1979  "Consolidation  of  Inspection  Ideology."  Concept  of  software  inspection 
formally  promoted  as  extending  beyond  testing,  to  evaluation  of  final 
products  and  the  development  process. 

"Quality  Assurance  through  Organization"  effort  launched.  Formalization 
of   QA    as    an    organizational    function    not    restricted    to    inspection 
but  extending  to  design   and  planning. 

Phase  Completion    Reporting   System  instituted. 

1980  Development  Planning  and  Report  System  (Version  No.  2)  instituted, 
adding   productivity  data  and    review  data    reporting. 

Campaign   to  increase  quality  three-fold  and  productivity  30%  by   1982. 

Software  Division  actively  promotes  small-group  activities  as  part  of  the 
company-wide  High-Reliability   Program. 

Software  Division  Quality  Objectives  established  --  formalization  of 
procedures  for  establishing   project  estimates   and   standard  times. 

"Diffusion  of  Inspection  ideology  through  Horizontal  Development." 
Effort  to  spread  knowledge  and  "good  practices'  horizontally,  i.e. 
beyond  one's  own   department. 

1981  "Advancement  of  Quality  Concepts"  movement  begun,  including  ease  of 
use  evaluations  (ESP)  and  QAL  (Quality  Assurance  Liaison)  initiated  to 
facilitate  inter-departmental   sharing  of  data  on   bugs. 

1982  "Performance  checking"   begun   directed   by    Inspection    Department. 

Quality  Objectives  control  system  instituted  and  Software  Quality 
Subcommittee  established. 

Six  program  development  departments  established  at  Numazu  Works  and 
located   in   new  software  building. 

1983  New  Software  Division  centralizes  all  basic  software  in   Numazu  Works. 

1984  Software  Division  extends  quality  assurance  and  quality  circle  activities 
to  software  subcontractors,  as  part  of  the  second  company-wide  High- 
Reliability   Program. 

Source:  Fujitsu  Ltd.,  Quality  Assurance  Department,  "Kensa-bu  no  rekishi" 
(History  of  the  Inspection  Department),   undated  internal  Fujitsu  memo. 
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Table  7.4:    DEVELOPMENT   PLANNING    ITEMS  AND   RESPONSIBILITIFS 

Key:         C  =  Control,    P  =   Planning,    E  =   Engineering,    D  =   Development, 

T  =    Integration   Testing,    I    =    Inspection,    o  =    included   in   Activities, 
X  =  Major  Responsibility 

Groups   Responsible  for  Checking 
Items  Check  Points  C         P         E         D        Ji 

QUALITY  OBJECTIVES: 
Development  Program  positioning,  o  X         o         o  o  o 

Objectives  development   results, 

marketability 


Desired 
Functions 

Performance 


User  needs  and 
program  functionality 

Objectives,    measures, 
comparative  analyses, 
appropriateness  of  the 
measurements 


X 


o  X 


XX 


Compatibility 


Reliability 


Objectives,    appropriate- 
ness  and  completeness 
of  the  objectives 

Appropriateness  of  the 
objectives,    likelihood 
of   implementation 


X         o  o  o  X 


o         o 


o  X 


PLANNING   IMPLEMENTATION 

Development  Appropriateness  of 

Size,    Language        size  given   functions, 

modularization/ reuse 


o  o 


Development 
Process 


Man-Power 
Machine  Time 


Review  &  Test 
Plans 


Appropriateness  of 
delivery  time  to   user, 
feasibility 

Match  of  productivity 
and  budget,    man-power 
allocations,    subcontract- 
ing percentage,    progress 

Amount  of   reviews   &  test, 
appropriateness  of  bug 
detection    (compared   to 
phase  standards) 


X        o 


X        XX 


X        X 


Work  Objectives 


Sufficiency  of  measures 
for  improving  quality 
and  efficiency 


X        o 


Development 
Structure 


Organization,    work 
distribution 


o  o 


Source:  Morita   and    Kanda,    p.    91 


Table  7.5:   MAJOR  SYSTEMS  SOFTWARE  DEVELOPMENT  TOOLS   (19831 

DESIGN 

YAC  II  (new  version  1987)  (Yet  Another  Control  Chart).  Detailed  design 
language,    combining  aspects  of  conventional   flow  charts   and   pseudo  code. 

PROGRAM  EDITING/CODE  GENERATION 

GEM  (1979)  (Generalized  Program  Editing  and  Management  Facilities). 
Automatically  maintains  a  development  history  of  a  program.      Linked  to  PRISM. 

PRISM  (1982)  (Problem  and  Repair  interrelated  System  Management  Extended). 
Maintains  a  data  base  of  the  program  source  and  automatically  tracks 
maintenance  changes.      Linked  to  GEM. 

COMPACT  (1982)  (Compact  Print-out  Utility).  Compacts  and  prints  out  compiled 
and  assembled  code. 

TOOL  2  (1983)  Allows  on-line  search,  from  time-sharing  terminals,  of  program 
source  code  and   lists. 

YPS  (1987)  (YACII  Programming  System).  Allowed  the  user  to  edit  YACII 
diagrams   and  then   automatically  generated  code   in    several    languages. 

TESTING 

SAT/ART  (1980)  (Systematic  and  Automatic  Testing/Automatic  Regression 
Testing).     Automated  regression  testing  tool  for  operating  system  development. 

TDQS  (1977)  (Test  Tool  for  DQS).  Automated  regression  testing  tool  for  on-line 
display  operations. 

INDS  (1983) .  (Interactive  NCP  Debugging  System) .  Allows  checking  and  analysis 
of  NCP  test   results  from  time-sharing  terminals. 

MTS  (1971,  1977)  (Multi-Terminal  Simulator).  Simulates  remote  terminals  for 
host  load  testing. 

TIOS  (1977).  (Time-Sharing  System  Input/Output  Simulator) .  Simulates  remote 
terminals  for  host  load  testing. 

HTS  (1977)  (Hardware  Trouble  Simulator).  Simulators  hardware  bugs  for 
functional  test  evaluations  of  software   responses. 

DOCK/FORT77  (1981).  Debugging  system  for  FORTRAN,  using  a  "slow  video 
display.  " 

PIC  (1984)  Program  Information  Control  System.  Allows  inspection  and  analysis 
of  memory-dump  lists  from  time-sharing  terminals.  Linked  to  the  Kamata- 
Numazu   Dump  Transfer  system. 

ATOS  (1982)  AIM  Test  Oriented  System.  Automatically  records  on  computer 
data   base   results  from  testing   and   inspection. 
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DOCUMENTATION 

ODM     (1983)     (Office    Document    Manager).         Document    handling    system    for 
Japanese  language. 

MANUAL   COMPILATION   AUTOMATION   SYSTEM    (1979).      Automated  editing  of 
electronic  documentation  files. 

EGRET-4   (1983)    (Easy  Graphic   Report  Generator). 

ATLAS    (1982).        Automatic    translation    of    Japanese    documents    into    English. 
English   to  Japanese  system  added   in   1986. 

MAINTENANCE 

TDP  II   (1980)    (Total  System  for  Difficulties  Information  Processing).   Data  base 
for  software   report  information. 

ITS    (1981)    (Incident    Tracking    System).    Control    system    for    questions    from 
customers. 

KAMATA-NUMAZU    DUMP    TRANSFER     (1982).     On-line    transfer    of    data    and 
reports  on   bugs.    Linked  to   PIC  testing   tool. 

PDE  (1983)    (PTF  Document  Editor).     Automatically  edits  documents  on  program 
corrections,    based  on   TDP    II    data. 


CONTROL 

BSMS    (1976)    (Basic   Software   Project  Management  Support  System).    Data  base 
and  control   tool   for  software  project  management. 

NOA   (1978)    (Numazu  Office  Automation).    Employment  data  control   system. 

IN-HOUSE  TRAINING  DATABASE  SYSTEM  (1982) .  Relational  database  system  for 
in-house  training  administration. 


Source:  "Sofutouea   kaihatsu,"   pp.   37,   44. 


83  Fujitsu 


Table  7.6:    SYSTEMS  SOFTWARE  DEVELOPMENT   PERFORMANCE  MFASURFS 

Notes:  AH  data  are  estimates  based  on  graphs,  and  therefore  are  approximate 
figures  only.  1983-1985  is  based  on  internal  Fujitsu  data.  Bugs/1000  LOC 
refers  to  all  bugs  reported  by  users  per  1000  lines  of  code  over  6- 
month  periods  (averaged  in  the  table  below)  in  the  field,  i.e.  newly 
delivered  code  plus   supported  outstanding  code. 

Bugs/  Bug  Detection  Method   (Estimates) 

1000  Test  Source  Code        Design   Sheet 

LOC  Review  Review 


1975 

•  ■  • 

•  •  • 

•  •  • 

1976 

1977 

0.19 

85% 

15% 

--% 

1978 

0.13 

80 

15 

5 

1979 

0.06 

70 

20 

10 

1980 

0.05 

60 

25 

15 

1981 

0.04 

40 

30 

30 

1982 

0.02 

30 

30 

40 

1983 

0.02 

1984 

0.02 

•  ■  • 

1985 

0.01 

•  •  • 

Source:  Yoshida  Tadashi,  "Sofutouea  no  keiryo-ka"  (Software  quantification), 
Joho  shori  (Information  Processing),  Vol.  26,  No.  1  (January  1985),  p. 
49;    and   Yoshida   interviews. 
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Table  7.7:   CHRONOLOGY  OF  APPLICATIONS  SOFTWARE  PROCESS  HFyFIOPMENT 

1964  Establishment  of  Systems   Department. 

1970  Centralization  of  applications  systems  development  at  Information 
Processing  System   Laboratory  in   Kamata,    Tokyo. 

1976  Establishment  of  Software  Engineering  Team  within  Systems  Department 
to  develop   SDEM    (Software   Development   Engineering  Methodology). 

1977  Establishment  of  Software  Conversion    Factory  and   SDEM  standards. 

1977  ERG  (Executive  Planning  Guide)  and  C-NAP  (Customer  Needs  Analysis 
Procedure)    commercialized   for  in-house   use  and   sale. 

1978  Introduction   of  SDSS    ((Software  Development   Support  System). 

1979  Establishment  of  Software   Factory   Department   in    Kamata. 

1980  SDEM  standards  commercialized  for  sale. 

1981  YAC    (Yet  Another  Control   chart)   developed  for  design   notation. 

1981  Commercialization  of  PARADIGM  (methodology  and  tool  for  developing 
reusable  programs). 

1982  Commercialization  of  BAGLES  (Banking  Application  Generator's  Library 
for  Extensive  Support). 

1983  SIMPLE  tool-set  introduced  for  commercial  sales,  beginning  with  LINDA 
(Logical  Information  Support  Tool  of  Dataset)  and  DBSP  (Data  Base 
Support   Program). 

1983         YACII   and  YPS    (YAC   II    Programming  System)   developed. 

1983  SDT   (SDEM  Design  Technique)   developed. 

1984  On-line  SDEM  developed. 

1985  ACS-APG  (ACS  Application  Program  Generator)  from  the  SIMPLE  series 
commercialized. 

1987  DRAGON  (Driver  and  Stub  Generator  for  On-line  and  Batch  Test)  from 
the  SIMPLE  series  commercialized. 

SDAS     (Systems     Development    Architecture    and    Support    Facilities) 
commercialized. 

EPGII/CNAPII    commercialized,    adding    to    1977    version    design    concept 
and  data-analysis  capabilities 

Source:  Noritoshi  Murakami,  Personal  Correspondence  to  Cusumano,  received 
12/26/88. 
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Table  7.8:      ACS   PARADIGM  PRODUCTIVITY  EXAMPLE 


Standard 

Project   1 

Project   2 

Manual 

ACS 

Extension   & 

Cobol 

Actual  Times 

Conversion 

Man-Months: 

System  Design 

2.5 

1.3 

5.5 

Program  Design, 

Coding, 

,      9 

5.5 

10.7 

Integrated  Test 

System  and  Operations  4  1.4  3 

Test 

Total  Man-Months  15.5  8.2  19.2 

Lines  of  Code  9,100  10,003  35,789 

Productivity  587  1,219  1,864 

(Lines/Man -Month) 

Documentation  170  160  50 

(Sheets) 

Faults/1000  lines  --  1  1.5 

(After  Operations  Test) 

New/Changed  Code  %  --  12  58 

Generated/ Reused  Code  %       --  --  42 


Paradigm  Definitions 

(Lines  of  Code)  1817 

(Man-Months)  12 

Total  Man-Months  --  20.2 

Net  Productivity  --  495 

(Lines/Man -Month) 


Source:  Derived  from   Kometani   and   Arakawa,    pp.    452-453. 
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Table  7.9:      COBOL.    BAGLES.    AND  BAGLES/CAD  PRODUCTIVITY  COMPARISON 

Design  Programming  Testing  Total 

COBOL  30  42  28  100 

BAGLES  35  15  25  75 


BAGLES/         20  18  22  55 

CAD 


Source:  Tsubuhari,    p.    231 
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Table  7.10:    BANKING   SYSTEM  DEVELOPMENT   PRODUCTtVITY 


Old  System  New  System 

System   Length  3,600,000   LOC  8,300,000   LOC 

Reused  Code  1,080,000  LOC   (30%)  6,550,000  LOC   (79%) 

New  Code  2,520,000  LOC  1,750,000  LOC 

Total    Productivity  450   LOC/Man-Month  902   LOC/Man-Month 


Source:  Fukuta  Zenichi,  Yoshihara  Tadao,  and  Maruyama  Takeshi,  "SDAS  sogo 
kaihatsu  shisutemu  no  teisho"  (SDAS  Systems  Development  Architecture 
and  Support  Facilities),   Fujitsu.  Vol.  39,   No.   1   (January  1988),   p.   11. 
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Table  7.11:      USE  OF  SOFTWARE  CAD   FOR  TOOL  DEVELOPMFNT 


Key:  K-LOC  =   1000  lines  of  cod 
MM  =  Man-Months 
MH  =  Man-Hours 
mo.=  month 


Task:   Tool   Development 

Tool   for  Converting 
Job-Flow   Diagrams   to 
Job-Control    Language 
(7.5   K-LOC   in   C) 

Tool   for  Converting 
Database  Structure 
Diagrams  to  ADL 
(High-level    Language) 
(6.7   K-LOC  in   C) 


Conventional 

9.3  MM/6  mo. 


Software  CAD 

0.5  MM/1    mo.      6-fold 


Development 

Time 

Improvement 


8.4  MM/6  mo.      0.5  MM/1    mo.      6-fold 


Task:      Program  Development 

Software  to  Convert 

Screen    Format  to  2.3  MM 

Definition    Language 

(100  screens) 

Software  to   Implement 

Screen  Transformation  to  8.0  MM 

Programming   Language 

(10/screen) 

Software  to   Implement 

Database  Structure  6.0  MH 

Diagram  to  ADL 


0.6  MM 


4-fold 


2.0  MM 


4-fold 


2.0  MH 


3-fold 


Source:  Yabuta,    Yoshioka,    and  Murakami,    p.    7. 
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Table  7.12:      FUJITSU   SUMMARY 


CONCEPT 


IMPLEMENTATION 


Process   Improvement 


Commitment  at  division-level  management  in 
early  and  mid-1970s  to  improve  process  and 
quality  control  in  basic  software.  Commitment 
to  structure  and  standardized  custom 
applications  development  from  late  1970s  and 
early   1980s. 


Product-Process   Focus 
&  Segmentation 


Development   sites,    tools,    methods,    and 
standards     divided     among     basic    software    and 
applications.        Largest    network    of    specialized, 
general,      and     regional     subsidiaries     among 
Japanese  computer  producers. 


Process/Quality 
Analysis   &  Control 


Systematic  data  collection,  document  and 
product  inspection  and  release  procedures, 
standardization  efforts.  Development  Planning 
and  Report  System,  and  BSMS  data  base  from 
mid-1970s  in  basic  software.  Similar  standards 
in  applications  from  late  1970s.  Systematic 
quality  data  collection  from  the  late  1970s, 
integrated  with  High-Reliability  Program.  Use  of 
Taguchi   methods   in   testing   basic   software. 


Tailored/Centralized 
Process  R&D 


Tools  and  methods  distinct  to  product  groups, 
with  some  transfers.  Software  tool  and  method 
development  first  centered  in  Numazu  (basic 
software)  during  early  1970s.  Kamata  in  late 
1970s  and  1980s  developed  methods  and  tools  for 
applications,  with  assistance  from  central 
laboratory. 


Skills 

Standardization 
&  Leverage 


2  to  3  months  standard  training  for  all  soft- 
ware personnel.  Courses  and  career  paths  to 
promote  advancement  and  specialization. 
Development  of  standardized  tools  and  methods 
specifically  to  leverage  knowledge  of  skilled 
personnel.  Division  of  labor  in  the  applications 
software  factory  between  system  engineering  and 
program  construction,  though  gradual  trend  of 
doing  more  program  and  system  design  in  the 
factory. 


Dynamic  Standardization 


Performance  standard  times  revised  annually. 
Continual  evolution  of  standardized  tools  and 
methods,    particularly   tools. 
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Systematic  Reusability 


In  applications,  emphasis  on  reusable  designs  and 
packages  that  can  be  incorporated  in  customized 
systems.  Wide  array  of  tools  to  support  reuse, 
some  dedicated  to  specific  applications  like 
banking.  In  basic  software,  emphasis  on  building 
common   components   for  different  products. 


Computer-Aided  Tools 


Extensive  investment  in  tools  during  the  1980s  to 
facilitate  the  transformation  of  designs  into 
executable  code  or  the  reuse  of  designs  and 
code,  such  as  PARADIGM,  ACS-APG,  CASET, 
YPS,  BAGLES,  and  Software  CAD.  Other  tools 
available  since  the  1970s,  such  as  ADAMS  and 
BSMS,  to  support  project  and  library 
management,    maintenance  and   testing. 


Incremental 

Product 

Improvement 


Emphasis  in  the  1970s  on  process  and  defect 
control,  as  well  as  evaluating  products  from 
customers'  perspective  (comparing  performance 
with  documentation).  Recent  emphasis  in  the 
1980s  on  improving  product  functionality  and 
ease  of  use,  with  quantified  measures.  Computer- 
aided  tools  apparently  useful  in  channeling  more 
relative  effort  into  design  and  less  into  coding. 
Overall,  strong  product  positions  in  basic 
software,  applications  engineering,  Japanese 
language  processing. 


ASSESSMENT: 


Strategic  Management 
&   Integration 


Long-term  effort  first  in  basic  software  to 
improve  the  development  process,  directed  by 
the  Inspection  and  Quality  Assurance 
Department  at  Numazu.  Similar  effort  in 
applications  software  directed  by  groups  in 
Kamata,  currently  the  SE  Technical  Support 
Center.  Company-wide     and     group-wide 

integration  and  technology  transfer  through  the 
Software  Development   Planning  Group. 


Scope  Economies 


Building  of  unique  and  customized  systems 
centralized  in  Numazu  and  Kamata,  as  well  as  in 
subsidiaries  and  software  houses  working  under 
the  direct  control  of  Numazu  and  the  Kamata 
Software  Factory.  Specific  efforts  directed  at 
building  and  using  common  tools,  methods,  and 
software  components. 
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NOTES   TO  CHAPTER   7 

1.  This  reflects  the  introduction  of  JEF  (Japanese-processing  Extended  Feature) 
in  1979,  which,  along  with  a  successor  version,  quickly  became  the  market 
leader  in  Japanese-language  word  processing  packages. 

2.  See  Table  4.1. 

3.  Nikkei  Computer.    13  October  1986,    p.    75. 

4.  Fujitsu   Limited,    "Numazu   kojo"    (Numazu  Works),    undated  brochure. 

5.  Fujitsu  Kabushiki  Kaisha,  "Kaihatsu  taisei:  Densanki  Jigyo  Honbu,  Sofutouea 
Jigyobu"  (Organizational  structure.  Computer  Group,  Software  Division), 
unpublished  company  document,    1986. 

6.  Interviews  with  Tadashi  Yoshida,  General  Manager,  Quality  Assurance 
Department,  Software  Division  (Numazu  Works) ,  Fujitsu  Limited,  7/31/86,  9/7/87, 
8/22/89,    and  written   responses  to  a  draft  of  this  chapter,    12/8/88. 

7.  Shimoda  Hirotsugu,  Sofutouea  ko}o  (Software  factories),  Tokyo,  Toyo  Keizai 
Shimposha,  1986,  p.  82;  interview  with  Katsuro  Yamaji,  Deputy  General  Manager, 
Software  Division,  Fujitsu  Ltd.,  7/31/86;  interview  with  Mamoru  Mitsugi,  Senior 
Executive  Director  and  General  Manager,  Systems  Engineering  Group,  Fujitsu 
Limited,   8/25/88. 

8.  Interview  with  Hiroshi  Narafu,  Section  Manager,  Software  Factory 
Department,    Fujitsu   Limited,   8/23/88,    and  written  correspondence,    12/6/88. 

9.  Interviews  with  Noritoshi  Murakami,  Manager,  Software  Development  Planning 
Group,    Fujitsu   Limited,   9/1/87,   3/22/88,    and  8/23/88. 
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10.  Major  sources  for  the  corporate  history  are  Usui  Kenji,  "FACOM  kaihatsu 
shi"  (History  of  FACOM  development),  Computopia.  April  and  May  1975; 
Iwabuchi  Akio;  Fujitsu  Kabushiki  Kaisha,  Fujitsu  Kabushiki  Kaisha  shashi  II 
(History  of  Fujitsu,  Ltd.),  1976,  reprinted  in  Nihon  Shashi  Zenshu  Kankokai, 
Nihon  shashi  zenshu:  Fujitsu  shashi.  Tokyo,  1977;  "FACOM  no  ayumi"  (FACOM 
history),    FACOM  ianaru.   Vol.    11,    No.    1    (1985),    pp.    20-47. 

11.  Minamisawa  Noburo,  Nihon  konpyuta  hattatsu-shi  (History  of  the 
development  of  Japanese  computers),  Tokyo,  Nihon  Keizai  Shimbunsha,  1978,  p.  145. 

12.  Iwabuchi  Akio,  Fujitsu  no  chosen  (Fujitsu's  challenge),  Tokyo,  Yamate 
Shobo,  1984,  pp.  34-42,  128-129,  198-202;  Ogino  Yuji  etal.,  "Fujitsu-Hitachi  no 
shin-konpyuta  'M  shirizu'  no  senryaku  o  tettei  kyumei"  (A  close  look  at  the 
strategy  of  the  new  Fujitsu-Hitachi  M-series'  computers),  Computopia.  February 
1975,    p.    17-18. 

13.  Usui,  Computopia.  May  1975,  pp.  17-18;  Japan  Economic  Journal.  29  January 
1985,    p.    10. 

14.  Iwabuchi,    p.   93;    Nikkei  Computer.    13  October  1986,    p.    81. 

15.  Ogino,    pp.   30-31. 

16.  Narafu   interview. 

17.  Fujitsu,  Information  Processing  Group,  No.  1  Software  Division,  "Sofutouea 
kaihatsu:  hinshitsu-seisansel  kojo  ni  tsuite '  (Software  development:  quality  and 
productivity  improvement) ,  unpublished  company  document,  received  9/24/85,  p. 
3. 
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18.  Computerworld.  5  December  1988,  pp.  1,  4;  The  New  York  Times.  30 
November  1988,    p.    1;    Businessweek.    19   December   1988,    pp.    100-102. 

19.  "Sofutouea   kaihatsu,"   pp.   40-41;    Yoshida   interviews. 

20.  Nihon   Keizai  Shimbun,    5  August  1987,    p.   9. 

21.  This  discussion  is  based  on  Kawaguchi  Izawa,  "Shoki  no  shisutemu 
sofutouea:  FONTAC  8040  MONITOR  no  kaihatsu  made  o  chushin  to  shite" 
(Early  systems  software:  focus  on  period  through  the  FONTAC  8040  MONITOR 
development),  Joho  shori.  Vol.  24,  No.  3,  March  1983,  pp.  225-237;  Usui  (May 
1975),  pp.  20-21,  25;  Okamoto  Akira,  "MONITOR-V  shisutemu  no  omoide" 
(Recollections  of  the  MONITOR-V  system),  in*  Kyoto  Daiqaku  Ogata  Kensanki 
Senta  10-nen-shi.  pp.  224-229;  Fujitsu  shashi  II,  p.  104;  Yamamoto  Takuma, 
"Opereteingu  shisutemu  kaihatsu  no  omoide"  (Recollections  on  operating  system 
development),  in  Kyoto  Daigaku  Ogata  Keisanki  Senta,  ed.,  Kyoto  Daiqaku  Ogata 
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